Post on 12-Feb-2017
Nerea Ledo Guede
Laureano Lambán Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
OmniController. Infraestructura coordinada SDN y OpenFlow
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: publicaciones@unirioja.es
OmniController. Infraestructura coordinada SDN y OpenFlow, trabajo fin degrado
de Nerea Ledo Guede, dirigido por Laureano Lambán Pardo (publicado por la Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
OmniController Infraestructura coordinada SDN y OpenFlow
Autor:
Nerea Ledo Guede Tutor:
Laureano Lamban Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática Dpto. Matemáticas y Computación
Grado en Ingeniería Informática Universidad de La Rioja
Curso académico 2014/2015
Logroño, La Rioja
2 OmniController | Ledo Guede, Nerea
3 Ledo Guede, Nerea | OmniController
Agradecimientos
Agradezco a Masscomm Innova y Alcatel-Lucent esta oportunidad, especialmente a mi tutor Borja
Reinares, a los expertos Miguel Izquierdo y Sergio Gómez, así como a Juan Nieto, por su interés
mostrado en todo momento.
Agradezco a la Universidad de La Rioja estos años de estudio, además de a mi tutor Laureano
Lamban, que me ha apoyado e impulsado a lo largo del desarrollo de mi trabajo fin de grado.
Por último, a mi madre y Pepe por estar siempre a mi lado.
4 OmniController | Ledo Guede, Nerea
5 Ledo Guede, Nerea | OmniController
Resumen
OmniController: Infraestructura coordinada SDN y OpenFlow es un proyecto de desarrollado
orientado a redes cuyo objetivo es facilitar a los operadores de red sus tareas de administración en
la red de la empresa. El cliente es la empresa Masscomm Innova bajo petición de Alcatel-Lucent.
La solución desarrollada permitirá centralizar las labores de administración propias de la red de
conmutación de la empresa y de los componentes hardware que forman parte de la misma.
Mediante el uso de técnicas aplicables a redes definidas por software (SDN), el protocolo de
comunicación OpenFlow y la herramienta de control OpenDayLight conseguimos:
- Facilitar la administración de la red SDN de la empresa.
- Disminuir la carga de trabajo del grupo de administración de red.
- Optimizar el rendimiento de arquitectura de red para servicios Cloud y Big Data.
Summary
OmniController: Infraestructura coordinada SDN y OpenFlow is a network-oriented solution
developed to expedite the network operators tasks at the company. The client is Masscomm Innova
on request of Alcatel-Lucent.
The solution developed will allow to centralize the conmutation network tasks of the company and
the administration of the hardware components that are part of it.
Through the use of techniques applicable to Software Defined Networks (SDN), the communication
protocol OpenFlow and the control tool OpenDayLight we get:
- Expedite the SDN network administration of the Company.
- Decrease the network administration group workload.
- Optimize the network architecture performance for Cloud and Big Data services.
6 OmniController | Ledo Guede, Nerea
7 Ledo Guede, Nerea | OmniController
Índice
Capítulo 1 – Introducción ...................................................................................................................... 11
1.1 Introducción .................................................................................................................................. 11
1.2 Entorno de desarrollo de TFG ....................................................................................................... 11
1.3 Descripción de tecnologías relacionadas con SDN ....................................................................... 12
1.3.1.1 ¿Por qué SDN? .................................................................................................................... 12
1.3.1.2 Beneficios SDN .................................................................................................................... 13
1.3.1.3 Arquitectura SDN ................................................................................................................ 13
1.3.1.4 Seguridad en entornos SDN ................................................................................................ 14
1.3.2.1 Beneficios de OpenFlow ..................................................................................................... 15
1.3.3.1 ¿Cómo funciona? ................................................................................................................ 16
1.4 Tecnologías de desarrollo ............................................................................................................. 16
1.5 Objetivos del Proyecto .................................................................................................................. 18
1.6 Diagrama de hitos ......................................................................................................................... 18
Capítulo 2 – API OpenDayLight y entorno de desarrollo ...................................................................... 21
2.1 API OpenDayLight particularizado a nuestro Proyecto................................................................. 21
2.2 Seguridad ...................................................................................................................................... 22
1.3.1 SDN: Software –Defined Networking ...................................................................................... 12
1.3.2 OpenFlow ................................................................................................................................. 14
1.3.3 OpenDayLight .......................................................................................................................... 15
1.4.1 Python ...................................................................................................................................... 16
1.4.2 JSON ......................................................................................................................................... 17
1.4.3 HTML 5 ..................................................................................................................................... 17
1.6.1 Breve descripción de las tareas ............................................................................................... 19
2.1.1 Plug-in OpenFlow ..................................................................................................................... 21
2.1.2 Interfaz Dlux ............................................................................................................................. 21
2.1.3 Procesamiento de topologías .................................................................................................. 21
2.1.4 Defense4All .............................................................................................................................. 21
2.1.5 SNMP4SDN ............................................................................................................................... 22
2.1.6 OpenDayLight VTN (Virtual Tenant Network) ......................................................................... 22
2.1.7 Group Policy ............................................................................................................................. 22
2.1.8 Yang Tools ................................................................................................................................ 22
8 OmniController | Ledo Guede, Nerea
2.3 Maqueta ........................................................................................................................................ 23
2.4 Instalación OpenDayLight ............................................................................................................. 24
2.5 Puesta en marcha ......................................................................................................................... 25
2.6 Replanteamiento del entorno de ejecución del Proyecto ............................................................ 26
2.6.1.1 ¿Qué es Mininet? ................................................................................................................ 27
2.6.1.2 ¿Qué aporta Mininet a este Proyecto? ............................................................................... 27
2.6.1.3 Conexión entre Mininet y OpenDayLight. .......................................................................... 27
2.6.1.4 Solución para continuar con el desarrollo del Proyecto. .................................................... 28
2.7 Prueba de funcionamiento. .......................................................................................................... 28
Capítulo 3 – Replanteamiento de objetivos.......................................................................................... 31
3.2 Replanteamiento de objetivos ...................................................................................................... 31
3.3 Nuevo objetivo .............................................................................................................................. 32
Capítulo 4 – Desarrollo de la aplicación ................................................................................................ 33
4.1 Modificar flujo en la red ................................................................................................................ 33
4.1.5.1 Crear flujo como usuario de la aplicación........................................................................... 34
4.1.5.2 Borrar flujo como usuario de la aplicación ......................................................................... 34
4.2 Creación de subredes .................................................................................................................... 35
4.2.3.1 Crear VLAN como usuario ................................................................................................... 37
4.2.3.2 Eliminar VLAN como usuario .............................................................................................. 37
4.2.3.3 Listar VTN como usuario ..................................................................................................... 37
4.3 Estadísticas de la red. .................................................................................................................... 37
4.4 Detección de ataques de denegación de servicios ....................................................................... 38
4.5 Multicast en OpenDayLight........................................................................................................... 39
2.4.1 Versiones ................................................................................................................................. 24
2.4.2 Requisitos previos .................................................................................................................... 24
2.6.1 Mininet ..................................................................................................................................... 27
4.1.1 ¿Qué necesitamos? .................................................................................................................. 33
4.1.2 ¿Qué características podemos elegir? ..................................................................................... 33
4.1.3 ¿Qué acciones se pueden llevar a cabo? ................................................................................. 33
4.1.4 ¿Qué se puede hacer con las reglas de flujo? .......................................................................... 34
4.1.5 ¿Cómo usa el usuario final esta parte de la aplicación? .......................................................... 34
4.2.1 Subredes con VTN (Virtual Tenant Network)........................................................................... 35
4.2.2 SNMP4SDN ............................................................................................................................... 36
4.2.3 ¿Cómo utiliza el usuario final esta parte de la aplicación? ...................................................... 37
9 Ledo Guede, Nerea | OmniController
4.6 Maqueta con herramientas para el usuario ................................................................................. 39
Capítulo 5 – Gestión de Proyecto ......................................................................................................... 41
5.1 Planificación inicial ........................................................................................................................ 41
5.2 Planificación final .......................................................................................................................... 42
5.3 Resumen ....................................................................................................................................... 44
Capítulo 6 – Conclusiones y futuras mejoras. ....................................................................................... 45
6.1 Conclusiones ................................................................................................................................. 45
6.2 Futuras mejoras ............................................................................................................................ 45
Anexos
Anexo 1 – Instalación OpenDayLight
Anexo 2 – OpenFlow Plugin
Anexo 3 – Instalación Mininet y comentarios de uso
Anexo 4 – Instalación Virtual Tenant Network (VTN)
Bibliografía ............................................................................................................................................ 47
10 OmniController | Ledo Guede, Nerea
11 Ledo Guede, Nerea | OmniController
Capítulo 1 – Introducción
1.1 Introducción El acceso a Internet en las empresas ha supuesto muchas ventajas para los negocios, hasta el punto
de entenderse como una herramienta indispensable. Entre estas ventajas hay que destacar la
mejora de conocimiento de sus competidores y consumidores y la reducción de costes y tiempo en
sus transacciones diarias.
No obstante, algunos problemas provenientes del uso de Internet, también son importantes. No nos
podemos olvidar de la vulnerabilidad que Internet supone en el tema de seguridad. Para mejorar la
seguridad, se usan los cortafuegos y para asegurar que la información solo la puede leer el usuario al
que va destinada, se usa la encriptación, que codifica la información antes de ser enviada para luego
decodificarla al llegar a su destino. Otro procedimiento para mantener las transacciones seguras es
la certificación notarial, lo que permite asegurar que el emisor y el destinatario son las personas,
instituciones o empresas que dicen ser. Desde nuestro punto de vista, otra consecuencia negativa es
el coste de la reestructuración interna, ya que el acceso a la red supone un reciclaje de los equipos
informáticos, además del reciclaje de los empleados.
Aparte de las ventajas y desventajas que hemos comentado, que son las básicas y en las que todo
empresario piensa, no nos podemos olvidar de la importancia que tiene que la red de una empresa
“no se caiga”, tenga velocidad adecuada, etc. Hablando en términos un poco más técnicos sobre
redes informáticas, estos problemas aparecen por pérdida de paquetes, saturación de puertos,
saturación de enlaces, alto nivel de jitter (señal de ruido no deseada debido a la variabilidad
temporal durante el envío) o alto nivel de delay (retraso sobre todo en audio o video), entre otros.
Para mejorar estas últimas opciones, sin que el administrador de la red de la empresa tenga que
ocupar mucho tiempo, se está imponiendo un tipo de solución como la que ha inspirado esta
propuesta de TFG. Dicha solución es la creación de sistemas “expertos” que, en base a una serie de
posibles condiciones (saturación, pérdida de paquetes, etc.) puedan definir una serie de reglas a
aplicar (priorizar tráfico, forzar al tráfico a seguir un enlace determinado, enviar un mensaje a los
administradores informando de lo que está ocurriendo). Estas opciones deberán poder ser
configuradas por los clientes, para tener un sistema propio y configurable dependiendo
características propias de la red de la empresa.
Para este tipo de solución se usa SDN (Software-Defined Networking), que abstrae la funcionalidad
inferior de la gestión de redes; y la tecnología OpenFlow, usada para la comunicación entre el plano
de control y el plano de datos.
1.2 Entorno de desarrollo de TFG El presente TFG se ha desarrollado por indicación y bajo la supervisión de la empresa Masscomm
Innova. Esta empresa, además de vender productos y tecnología, ofrece a las empresas clientes
soluciones a sus problemas de negocio.
Una de las tecnologías que ofrece son productos de redes IP y diversas componentes basadas en
estándares IP (conmutadores lan l2/l3, soluciones wlan, routers, etc.). Para facilitar la administración
12 OmniController | Ledo Guede, Nerea
y configuración de estos sistemas, se propone la realización de este Trabajo Fin de Grado (TFG).
Además, el Proyecto se hace conjuntamente con Alcatel-Lucent Madrid, que ofrece sus switches
(dispositivos de interconexión de equipos que operan en la capa de enlace de datos del modelo OSI,
para interconectar segmentos de red pasando datos entre ellos) y sus conocimientos sobre las redes
en las empresas.
1.3 Descripción de tecnologías relacionadas con SDN Definimos a continuación algunos términos relacionados con las tecnologías y herramientas
software que es necesario conocer para llevar a cabo el trabajo que se pretende desarrollar.
1.3.1 SDN: Software –Defined Networking
Las redes definidas por software (SDN), tienen como objetivo facilitar la implementación e
implantación de servicios de red de una manera dinámica y escalable, evitando al administrador de
red gestionar los servicios a bajo nivel. Separa el control de la red de las funciones de reenvío con
una API definida entre ambas, que permite la programabilidad del control de red y la abstracción de
la infraestructura subyacente.
La automatización de la gestión de la red, a través de SDN, es la siguiente fase en la virtualización de
la infraestructura de tecnologías de la información y las telecomunicaciones.
1.3.1.1 ¿Por qué SDN?
Las redes actuales tienen unas limitaciones considerables en cuanto a complejidad, consistencia,
escalabilidad y dependencia del vendedor. Esto hace que, en general, sea solo una solución temporal
para los departamentos IT (tecnológico de la información) de infinidad de empresas y proveedores
de servicios de red.
Algunos de los motivos por los que las redes tradicionales están llegando a sus límites y es necesaria
una nueva arquitectura son:
Heterogeneidad en los patrones de tráfico: las aplicaciones modernas crean tráfico máquina
a máquina mediante accesos a bases de datos y servidores, antes de enviar los datos al
usuario final, en contraposición con las aplicaciones cliente-servidor anteriores donde la
gran parte de la comunicación ocurre entre un cliente y un servidor. También es debido a
poder conectarse desde cualquier punto en cualquier momento, mediante las redes
inalámbricas.
Aumento de carga de trabajo a los administradores de red; nuevos dispositivos móviles
(smartphones y tablets) acceden a la red y, es necesario proporcionar mayor protección de
datos de usuarios y mantenimiento de seguridad en la red.
Aumento de servicios cloud: requieren una escalabilidad dinámica de la capacidad de
cómputo, almacenamiento y recursos de red.
Big Data y aumento de ancho de banda requerido. Big Data requiere un procesamiento
intensivo de miles de servidores, lo que lleva a una demanda constante de ancho de banda a
los proveedores de redes.
13 Ledo Guede, Nerea | OmniController
SDN es una arquitectura adecuada, ya que otorga una manera flexible de controlar el mundo de las
redes.
1.3.1.2 Beneficios SDN
- Reduce el Capex (Capital Expenditures): no es necesario invertir en hardware nuevo.
- Reduce el Opex (Operating Expense): permite el control de los elementos de red que cada vez son
más programables, haciendo más sencillo la configuración y gestión de redes. Esto permite una
reducción de tiempo de gestión por parte de los administradores, lo que supone una reducción
considerable del error humano.
- Agilidad y flexibilidad: despliegue de aplicaciones, servicios e infraestructuras rápido para reducir el
tiempo de alcance de los objetivos de una empresa.
- Permite innovación: crear nuevos tipos de aplicaciones y modelos de negocio que beneficia y
aumenta el valor de las redes de las empresas.
1.3.1.3 Arquitectura SDN
La ONF (Open Networking Foundation) especifica la arquitectura SDN con las siguientes capas:
- Capa de infraestructura: está constituida por los nodos de red que realizan la conmutación y
encaminamiento de paquetes. Proporciona un acceso abierto programable a través de API
hacia abajo (OpenFlow por ejemplo)
- Capa de control: la función de control de software está centralizada permitiendo a los
desarrolladores de aplicaciones utilizar las capacidades de red abstrayéndose de su
topología y funciones. El controlador SDN es quien controla y configura los nodos de red
para dirigir correctamente los flujos de tráfico. La arquitectura es independiente a los
14 OmniController | Ledo Guede, Nerea
protocolos utilizados por las interfaces de los sistemas hardware.
- Capa de aplicación: consiste en las aplicaciones de negocio de los usuarios finales, que
utilizan servicios de comunicación de SDN a través de las API hacia arriba de la capa de
control (ejemplo JSON), permite a los servicios y aplicaciones simplificar y automatizar las
tareas de configuración, provisión y gestión de los nuevos servicios en la red.
Para que la arquitectura SDN tenga éxito, debe poder ser desplegada en redes multivendedor,
asegurando la seguridad e interoperabilidad. Para asegurar la interoperabilidad entre los distintos
dominios, los vendedores de equipamiento deben desarrollar una API abierta a sus controladores
SDN, algo que actualmente está en un estado inicial, dada la complejidad en acordar un API
estándar.
1.3.1.4 Seguridad en entornos SDN
La seguridad, como en todo tipo de redes y en la mayoría de aspectos informáticos, es un aspecto
crucial. En las redes SDN es necesario proteger la disponibilidad, integridad y privacidad de la
información que transporta.
Aunque existe algún enfoque competente, no hay una idea en común, pero está claro que las
soluciones deben crear un entorno escalable, eficiente y seguro, además de tener una configuración
simple y efectiva.
En la arquitectura hay varios elementos que deben ser protegidos y acciones a llevar a cabo:
Asegurar y proteger el controlador.
Privacidad e integridad. Se debe asegurar el controlador, las aplicaciones que carga y los
dispositivos de red. Autenticarlos y comprobar su correcto funcionamiento.
Crear un framework de política robusto. Es necesario estar seguro de que el controlador y
demás dispositivos están haciendo lo que queremos que haga, por lo que habrá que realizar
comprobaciones continuas de los sistemas en general.
Llevar a cabo análisis forense de la red. Para poder determinar en caso de un ataque, quien
lo realizó, reportarlo y proteger la red de cara al futuro.
1.3.2 OpenFlow
OpenFlow es una de las implementaciones más populares de SDN y es recomendado por la ONF.
Se trata de un protocolo de bajo nivel que permite implementar el control de los nodos de red.
Además, es un estándar abierto que busca la interoperabilidad entre distintos fabricantes. El código
abierto es considerado por muchos operadores como la alternativa más rápida para conseguir
soluciones de interoperabilidad y multivendedor, respecto a la estandarización de las API que
requiere mucho más tiempo.
Con este protocolo, una red puede ser gestionada como un todo, no como un número de
dispositivos que se gestionan individualmente; es el propio servidor el que dice a los switches donde
deben enviar los paquetes. Con esta tecnología, las decisiones de movimiento de paquetes están
centralizadas, lo que permite una red programada independientemente de los switches.
15 Ledo Guede, Nerea | OmniController
1.3.2.1 Beneficios de OpenFlow
OpenFlow permite que las redes evolucionen dando a un controlador el poder de modificar el
comportamiento de los dispositivos de red a través de un conjunto de instrucciones de reenvío bien
definidas. Esto genera los siguientes beneficios:
- Crea flexibilidad en cómo la red se usa, se opera en ella y se vende. El software que lo
controla puede ser escrito usando un entorno de software común.
- Los operadores de red pueden implementar características que quieran en el software que
controlan, sin tener que esperar a que los fabricantes los ponga en marcha en sus propios
productos.
- Reduce el gasto de operación, lo que conduce a menos errores y por consiguiente menor
inactividad.
- Habilita la virtualización de la red y la integración con la informática y el almacenamiento.
Permitiendo que la operación de las TIC sea controlada con un solo punto de vista y con las
mismas herramientas.
- Acoge a mercados abiertos y diversos ya que se trata de una manera estándar de transmitir
la información de las tablas de flujo a los dispositivos de red.
1.3.3 OpenDayLight
Es una plataforma abierta para la programación de red que permite SDN y NFV (Network Functions
Virtualization, virtualización de la funciones de red).
Este software es una combinación de componentes que incluye un controlador totalmente
conectable, interfaces, protocolos de plug-in y aplicaciones.
En este trabajo se tiene previsto utilizar la última versión, Helium, que tiene una nueva interfaz de
usuario (Dlux) y usa el contenedor Apache Karaf. Además, ha evolucionado con sus antecesoras en la
disponibilidad, clustering, seguridad y la adición de nuevos protocolos como OpenFlow. Esta es la
razón por la que lo consideramos en nuestro desarrollo, ya que es OpenFlow la implementación de
SDN que pretendemos utilizar.
Aclarar que, en terminología OpenDayLight las capas definidas anteriormente en la arquitectura SDN
se traducen a:
- Red de aplicaciones, orquestación y servicio.
- Plataforma del controlador.
- Dispositivos de red físicos y virtuales.
16 OmniController | Ledo Guede, Nerea
1.3.3.1 ¿Cómo funciona?
El controlador proporciona APIs abiertas que son utilizadas por las aplicaciones. OpenDayLight
incorpora OSGi y REST bidireccional. El marco OSGi se utiliza para aplicaciones que se ejecutan en el
mismo espacio de direcciones que el controlador, mientras que el resto de APIs se utiliza para
aplicaciones que no se ejecutan en el mismo espacio de direcciones que el controlador. La lógica de
negocio y sus algoritmos relacionados residen en las aplicaciones. Estas utilizan el controlador para
reunir inteligencia, diseñar procesos para realizar análisis, y luego usar el controlador para orquestar
las nuevas reglas a través de la red.
La propia plataforma de controladores contiene una colección de módulos conectables
dinámicamente para realizar tareas de red necesarias. Hay una serie de servicios básicos de red: para
determinar qué dispositivos se encuentran en la red y las capacidades de cada uno, recopilación de
estadísticas, etc. Además, los servicios orientados a la plataforma y otras extensiones también se
pueden insertar en el controlador para aumentar la funcionalidad SDN.
1.4 Tecnologías de desarrollo
1.4.1 Python
El lenguaje de programación elegido para este Proyecto es Python, uno de los motivos principales es
la hegemonía que está teniendo este lenguaje en los últimos años, añadido a la motivación de
aprender un lenguaje nuevo. SDN tiene un buen funcionamiento tanto con Java como con Python,
teniendo el primero un descenso de usuarios y el segundo un ascenso de ellos (aunque la diferencia
sigue siendo destacable a favor de Java) como muestra la siguiente tabla.
17 Ledo Guede, Nerea | OmniController
Las ventajas que nos ofrece el lenguaje elegido son:
- Curva de aprendizaje baja. Fácil de aprender por el uso de mínimo líneas de código, la no
necesidad de declarar tipos y el no uso de llaves, lo que se evita tener que acordarse de
cerrar todas y en el lugar correcto.
- Pocas líneas de código, lo que da una facilidad tanto para el desarrollador que lo escribe
como para el que lo lee.
- Multiparadigma, lo que nos da un buen abanico de opciones de programar.
- Tipado dinámico, lo que permite reemplazar unos tipos por otros (este tipado tiene el
inconveniente de conversiones incorrectas a la hora de la ejecución, pero facilita los
contenedores, listas, etc.)
- Multiplataforma, por lo que no tenemos inconveniente en la utilización de ningún sistema
operativo.
1.4.2 JSON
Es un formato ligero para el intercambio de datos. Es elegido sobre XML, los únicos dos formatos
permitidos en OpenDayLight.
Su simplicidad y sencillez a la hora de escribir es uno de los motivos para la elección. JSON se emplea
habitualmente en entornos donde el tamaño del flujo de datos entre cliente y servidor es de vital
importancia.
JSON, a diferencia de XML, no permite incluir fotos, audio, video y otros ficheros, lo que evita el
peligro de incluir un fichero ejecutable que suponga consecuencias para la seguridad.
La forma de compartir los datos es utilizando vectores, mientras que XML se basa en árboles. Esto
supone una ventaja, ya que los datos se almacenan en estructuras familiarizadas en los lenguajes de
programación.
1.4.3 HTML 5
El lenguaje HTML5, es la última versión de HTML, lenguaje básico de la world wide web. Esta nueva
versión establece una serie de nuevos elementos y atributos que reflejan el uso típico de los sitios
18 OmniController | Ledo Guede, Nerea
webs modernos.
Las novedades a destacar son:
- Incorporación de etiquetas con codecs para mostrar los contenidos multimedia.
- Etiquetas para manejar grandes conjunto de datos (datagrid, menús, etc.)
- Nuevos tipos de datos (email, url, etc.) para los formularios.
- Etiquetas para manejar la web semántica, que permiten describir el significado del
contenido.
Esta elección de lenguaje es debido a la posibilidad de tener un buen diseño para tabletas y
smartphones.
1.5 Objetivos del Proyecto Este Proyecto tiene como objetivo principal facilitar el trabajo a los usuarios finales (encargados de
redes) en cuanto a la administración de redes de su empresa.
La aplicación a desarrollar proporcionará al usuario diferentes funcionalidades, tanto para marcar
nuevas características en la red, como para obtener algunas estadísticas de su uso.
El usuario podrá:
- crear redes lógicas independientes desde una misma red física (VLAN).
- activar filtros para defenderse de los ataques de denegación de servicio (DDoS).
- detectar determinados tráficos y cambiar su prioridad
- realizar un bypass a un firewall si este falla. (Hay casos de empresas reales, que por motivos
de seguridad y funcionamiento no pueden quedarse sin red, y señalan que bastantes veces
que tienen problemas es debido a un fallo en el firewall. Por ello, solicitan tener un “botón
rojo” que haga que deje de funcionar el firewall y exista una red sin él).
- realizar envío de información en múltiples redes a múltiples destinos simultáneamente. Esto
sería realizando multicast (multidifusión) a través de SDN.
- mostrar estadísticas de la red.
Estas funcionalidades no deben depender de la marca del hardware que haya debajo, gracias a la
tecnología SDN y OpenFlow.
1.6 Diagrama de hitos Este Proyecto está previsto que dure desde el 1 de febrero hasta el 1 de junio de 2015, teniendo un
hito principal cada mes, donde se tendrá la reunión con la empresa. Esta reunión se podrá adelantar
o retrasar al ritmo que se vaya realizando el Proyecto.
El Proyecto se va a dividir en semanas, pero las tareas a desarrollar serán descritas mensualmente.
Cada semana se tiene previsto realizar sobre 17 horas, siendo un total aproximado de 300 horas
previstas.
19 Ledo Guede, Nerea | OmniController
Tarea Semana 4
23/2-1/3
Semana 9
30/3-5/4
Semana 13
27/4-3/5
Semana 17
25/5-31/5
Maqueta
configurada
Estudio de
Python y JSON
Estudio API
OpenDayLight
AOS
App Python
App web
Piloto finalizado
App Android e
iOS
Proyecto
finalizado
Memoria
finalizada
1.6.1 Breve descripción de las tareas
Maqueta configurada: especificación, configuración y comprobación de la maqueta utilizada para
este Proyecto. Switch y capacidades de ellos, servidores utilizados para el desarrollo, máquinas de
pruebas, etc.
Estudio de Python y JSON: aprendizaje del lenguaje de programación y del formato para el
intercambio de datos.
Estudio API OpenDayLight: aprendizaje de la controladora SDN a utilizar
AOS: estudio y conocimiento de cómo funciona la plataforma de servicio de los switch de Alcatel.
20 OmniController | Ledo Guede, Nerea
App Python: realización de las funciones en el lenguaje de programación.
App web: realización de la interfaz gráfica de la aplicación.
Piloto finalizado: finalización del piloto (funcionalidades e interfaz gráfica)
App Android e iOS: paso de la aplicación web a sistemas operativos móviles más utilizados.
Proyecto finalizado: finalización del Proyecto completo, tanto desarrollo como pruebas.
Memoria finalizada: finalización de la memoria a entregar.
21 Ledo Guede, Nerea | OmniController
Capítulo 2 – API OpenDayLight y entorno de desarrollo
Se han presentado en el Capítulo 1 la noción de Software-Defined Networking (SDN), el protocolo
OpenFlow y la plataforma OpenDayLight. Antes de iniciar las instalaciones y configuraciones de
estas herramientas, es necesario familiarizarnos con la API de OpenDayLight, por lo que el primer
trabajo consiste en realizar un estudio de la misma.
Cabe destacar el alto número de aplicaciones que se van a usar y que todavía se encuentran en fase
de desarrollo, por lo que se van a probar versiones beta (aceptando las condiciones de uso de sus
licencias).Por tanto, el riesgo de encontrar problemas es alto.
2.1 API OpenDayLight particularizado a nuestro Proyecto Describimos a continuación las componentes proporcionadas por OpenDayLight que serán
relevantes para nuestro trabajo. Es una herramienta constituida a base de numerosas componentes,
de las que vamos a señalar solo las que se tiene previsto usar en nuestro Proyecto.
2.1.1 Plug-in OpenFlow
Como se ha comentado con anterioridad, el Proyecto a desarrollar utilizará el protocolo OpenFlow
que permite la interacción entre el control y la expedición de capas en una arquitectura SDN como
va a ser esta. La versión Helium de OpenDayLight trae por defecto instalado este plug-in, que se
puede desinstalar a través de la consola.
El plug-in mencionado da la posibilidad de tener en la controladora las especificaciones actualizadas
de este protocolo, además de ofrecer una librería que proporciona al usuario un canal de
comunicación, que puede ser utilizado para la gestión de dispositivos de hardware de red.
2.1.2 Interfaz Dlux
Se utilizará la interfaz Dlux integrada con OpenDayLight (también puede usarse de forma
independiente). Esta interfaz trabaja sobre Apache Karaf incorporando varios paquetes. Entre ellos
nos interesan los gestores de conexiones, red, flujos y topología. Todos ellos son interesantes para
este Proyecto ya que nos facilitarán información sobre la red con la que vamos a trabajar.
2.1.3 Procesamiento de topologías
Existe un proyecto en OpenDayLight que nos proporciona la posibilidad, mediante la construcción de
filtros, de limitar la información de la red que sea relevante para el administrador, es decir,
conseguir que únicamente se pueda acceder a la información deseada tras realizar un filtro.
Se usará principalmente para agregar y filtrar topología.
2.1.4 Defense4All
Uno de los objetivos del Proyecto es informar sobre ataques de denegación de servicios (DDoS) en la
red.
OpenDayLight tiene el proyecto Defense4All que detectará este tipo de ataques y desviará el tráfico,
basado puramente en vigilancia y control de las capacidades. Esta herramienta, funciona
independientemente sobre la detección de ataques, pero para la mitigación de un ataque real
depende de dispositivos especializados.
22 OmniController | Ledo Guede, Nerea
2.1.5 SNMP4SDN
El plug-in SNMP4SDN permite configurar los flujos en los conmutadores Ethernet, es decir, descubrir
qué interruptores están bajo su gestión y configurar los flujos sobre ellos. El citado plug-in será de
utilidad ya que trabajamos con una plataforma SDN. Además, ofrece utilidad para las tablas de
reenvío, ACL (lista de control de acceso), tablas VLAN, etc.
Estas funciones se pueden hacer a través de SNMP (protocolo simple de administración de red, que
facilita el intercambio de información de administración entre dispositivos de red) por lo que es
necesario su configuración en los switch de la red, o CLI (línea de comandos).
2.1.6 OpenDayLight VTN (Virtual Tenant Network)
En un principio, OpenDayLight VTN no se estima realmente necesario en este Proyecto, porque está
desarrollada para redes más complejas que con aquella que se va trabajar.
De todas formas, es una aplicación que hay que estudiar a fondo y probar ya que proporcionará
redes virtuales para múltiples usuarios. Ofrece una abstracción lógica sobre una red compleja que
permite la separación completa entre el plano lógico y el plano físico. Así, los usuarios podrán
diseñar y desplegar cualquier red deseada sin conocer las restricciones de topología de red o ancho
de bandas físicas. Las redes a diseñar, podrán ser tanto L2 como L3 convencionales.
Ofrece dos servidores recomendados. El primero de ellos, VTN Coordinator, es una aplicación
externa responsable de la virtualización. El segundo es un plug-in, VTN Manager, que ayuda a crear,
modificar y borrar componentes en la red e interactúa con el anterior.
2.1.7 Group Policy
El proyecto Group Policy, que forma parte de OpenDayLight, facilita un mecanismo de
autodocumentación para la captura de requisitos de políticas, la automatización para manipular más
fácilmente los grupos de puntos finales de la red y una manera coherente y concisa para manejar los
cambios de política de una forma extensible.
Esto, además, favorece a los usuarios futuros en cuanto a la abstracción, ya que separa la
información acerca de los requisitos de conectividad de la aplicación de los detalles subyacentes de
la infraestructura de red.
2.1.8 Yang Tools
Sin ser realmente importante para este Proyecto, que se va a realizar con el lenguaje Python, cabe
decir que OpenDayLight tiene un proyecto, Yang Tools, que proporciona apoyo de netconf (network
configuration protocol, protocolo de configuración de red) y lenguaje YANG (lenguaje de modelado
de datos, tanto de configuración como de estado de los elementos) a aplicaciones java.
2.2 Seguridad Al hablar de una red interna, normalmente perteneciente a una empresa, cerrar las posibles puertas
a usuarios ilícitos es uno de los objetivos principales.
Realizando el estudio de OpenDayLight, se ha encontrado una serie de recomendaciones para
construir un marco seguro en el controlador:
- Realizar un análisis de vulnerabilidades periódicamente para identificar los fallos de
23 Ledo Guede, Nerea | OmniController
seguridad que pueden ser explotados por los atacantes, tanto los fallos físicos como lógicos.
- Contar con un mecanismo para informar de errores/cuestiones de seguridad.
- Tener un equipo de gestión de vulnerabilidades.
- Incorporar un plug-in de syslog (estándar para el envío de mensajes de registro en una red)
que capture el análisis de incidentes de los dispositivos. Además tener un apoyo robusto de
respuesta a estos incidentes.
- Considerar un canal de comunicación seguro para conectarse a los plug-ins. Un
almacenamiento seguro de claves de cifrado y protección DDoS en los puertos de los plug-
ins, además de incorporar autoridad de certificación.
- Establecer el servicio de AAA (Authentication, Authorization and Accounting; autenticación,
autorización y contabilización) para aplicaciones, usuarios y dispositivos.
- Diseñar un marco para descubrir, conectar y configurar de forma segura los dispositivos.
- Establecer un mecanismo seguro para agrupar el controlador en cuanto a escalabilidad y
disponibilidad.
- Ya que los paquetes OSGi (Open Services Gateway Initiative), proporcionan un cierto nivel de
aislamiento con límites explícitos, se recomienda aumentar en tiempo de carga con
verificadores de firma y permisos, y en tiempo de ejecución con la seguridad de acceso a los
paquetes.
- Asegurar que las aplicaciones Bundle a insertar provengan sólo de fuentes verificables y de
confianza.
2.3 Maqueta Para el desarrollo de este Proyecto está previsto crear un escenario donde llevar a cabo las
instalaciones, configuraciones y desarrollos necesarios.
La maqueta estará compuesta por un switch de la marca Alcatel-Lucent siendo su modelo OS6860E-
P24. Este ha sido elegido por permitir, según indica su fabricante, las características necesarias para
hacer funcionar nuestro Proyecto, como es SDN y OpenFlow. Este switch ofrece dos formas de
conexión: la conexión modo full (donde solo existe el formato SDN), y la conexión modo híbrido,
donde existe el formato SDN y por línea de comandos (como cualquier otro switch).
En esta maqueta nos decantamos por el formato híbrido, para poder comprobar por consola las
modificaciones realizadas. En este modo, si se están mandando órdenes de las dos formas, primero
se escribirán las de consola y luego se sobrescribirán y/o sumarán las realizadas a través del
controlador SDN.
A este switch irán conectados dos clientes con sistema operativo indiferente (Windows 7 / Ubuntu
12.04 Desktop), comunicados a través del protocolo OpenFlow 1.3.1.
Además, tendremos dos servidores virtualizados con Ubuntu 14.04 Server. En uno se instalará
OpenDayLight, por lo que tendremos acceso a las características y opciones graficas de la interfaz
web Dlux. En el otro servidor se desplegará la aplicación escrita en Python, que podría disponer de
24 OmniController | Ledo Guede, Nerea
una interfaz gráfica para facilitar su uso.
El switch y el servidor de OpenDayLight se comunicaran utilizando JSON.
A continuación se muestra una imagen que representa, de forma esquemática, el diseño propuesto:
2.4 Instalación OpenDayLight Antes de comenzar con la instalación, es necesario conocer qué versiones existen de OpenDayLight
Helium y cuáles son sus requisitos previos.
2.4.1 Versiones
Distribución Helium:
- Helium – SR2 (Enero 2015) última versión en el momento de comenzar el Proyecto.
- Helium – SR3 (Marzo 2015). Durante el desarrollo del Proyecto, se actualizó el software de la
controladora que se estaba utilizando, por lo que se tuvo que reinstalar y reconfigurar lo que
se tenía hecho.
2.4.2 Requisitos previos
No tiene requisitos previos. Al ser una aplicación Java, se puede ejecutar en cualquier sistema
operativo que soporte Java, pero para obtener mejores resultados se recomienda:
- Ubuntu 12.04 o posteriores
- JVM 1.7
Después de este estudio y tras la recomendación explícita de la empresa, se inicia con la instalación
de la controladora en Ubuntu Server 12.04 (64 bits).
25 Ledo Guede, Nerea | OmniController
2.5 Puesta en marcha Se trata de poner en marcha la maqueta diseñada. Los pasos de instalación de la controladora
OpenDayLight se encuentran reflejados en el Anexo 1 (son independientes de la versión a instalar,
SR2 o SR3). A continuación, se inicia el servidor y se accede a la interfaz Dlux a través del navegador.
Sin embargo, tras estos primeros pasos se encontraron problemas que no se ha podido solucionar y
que han obligado a replantear los objetivos iniciales y a modificar sustancialmente el Proyecto. En
efecto, no hay ningún problema en la conexión con la interfaz, pero esta no muestra la topología de
red (algo que según consta en la documentación debería hacer automáticamente).
Por otra parte, nos podríamos plantear la
opción de crear los nodos directamente pero
esto no es compatible con nuestro interés de
control mediante software. Además, no hay
ayuda para saber qué datos hay que insertar
(a modo de curiosidad, para mejorar nuestro
conocimiento sobre OpenDayLight, se
realizaron diversas pruebas pero ninguna
funcionó)
26 OmniController | Ledo Guede, Nerea
Tras consultar la documentación de OpenDayLight (fundamentalmente se limita a una wiki), y foros
asociados a dicho proyecto, se barajan posibles causas para este fallo:
En primer lugar, OpenDayLight usa el protocolo LLDP (protocolo de descubrimiento de la capa de
enlace, los dispositivos de red publican su identidad y sus capacidades a sus vecinos de área local).
Se pensó que, al utilizar un servidor virtual en la red de la empresa, y al no ser posible la conexión a
través de un cable Ethernet, esto podría hacer que no funcionase de forma correcta el protocolo.
Tras preguntar al personal de la empresa, y obtener la ayuda de diversas páginas web sobre este
protocolo, se concluye que este no podría ser el fallo, ya que toda nuestra maqueta está instalada en
la misma red local.
Al no poderse determinar el motivo de fallo se plantearon diferentes alternativas modificando la
maqueta inicialmente diseñada:
Poner en el servidor virtual una “trampa” de conexión de cable para que crea que exista y
funcione LLDP. Los expertos de la empresa consultados, no creyeron posible esta opción y se
descartó.
Crear una máquina virtual a través de Virtual Box y conectar directamente el equipo donde
está instalado virtualmente el controlador con el switch. Tras la instalación y configuración
adecuada, no solo en esta nueva máquina virtual, sino también en la maqueta realizada
anteriormente (hay que cambiar las IPs utilizadas) se repite todo el proceso para visualizar la
topología, y tampoco resulta posible.
Otra posible explicación es la falta de alguna componente por instalar en nuestro servidor.
Al buscar información, se plantea que pueda faltar por instalar el plug-in OpenFlow, que se
ha comentado en el apartado 2.1 de este capítulo. Se instala como aparece en el Anexo 2,
pero no se observa ninguna modificación en el funcionamiento.
Otra posible explicación es la no aceptación de la versión del protocolo y se intenta con la
versión anterior (OF 1.0)
Se intenta cambiar el planteamiento y conexiones de los hosts y el switch en la red de la
empresa. Una primera idea es tener los host en dos máquinas virtuales con IP de la empresa
al igual que el switch. La modificación se realizó creando una subred privada que solo
conectase los host al switch y así evitar tráfico “sucio” que pueda interferir en el
funcionamiento.
Reconfiguración del switch con la ayuda de la empresa. Al reconfigurar el switch, se cuenta
con la ayuda de personal de la empresa que conoce los switches de Alcatel Lucent. Se llega
a la misma configuración realizada anteriormente pero no se consigue el funcionamiento
deseado.
2.6 Replanteamiento del entorno de ejecución del Proyecto Tras la ayuda de la empresa, y ver que el Proyecto corría riesgo de estancarse, se plantea realizarlo
con una red virtual, como la que nos ofrece la herramienta Mininet. Esta opción, aceptada tanto por
la empresa como por la universidad, da la opción de aprender sobre más cosas y seguir con el
Proyecto hacia adelante, aunque cambiando los objetivos.
27 Ledo Guede, Nerea | OmniController
Se trata de una modificación muy importante respecto del Proyecto inicial, obligando a eliminar
alguno de los objetivos fijados.
Es importante hacer notar que, en la última etapa del Proyecto, ha aparecido en la documentación
de OpenDayLight una nota que informa que éste solo ha sido probado con Mininet, lo que viene a
justificar todos los problemas con los que nos encontramos, como hemos relatado antriormente.
Tras este contratiempo, a las tareas planteadas con anterioridad se incorpora el estudio de la
herramienta Mininet.
2.6.1 Mininet
En este apartado se va a definir qué es la herramienta Mininet y cómo la vamos utilizar en este
Proyecto.
2.6.1.1 ¿Qué es Mininet?
Mininet es una herramienta que permite crear una red virtual con una colección de dispositivos
finales. Se puede interactuar fácilmente con la red a través de su línea de comandos (y de su API),
personalizarlos, compartirlos e interactuar con programas.
Las topologías son rápidas de crear y pueden ser sencillas o complejas, lo que favorece acercarse lo
máximo posible a redes reales de las utilizadas en empresas.
2.6.1.2 ¿Qué aporta Mininet a este Proyecto?
Mininet nos aporta una red que se asemeja a la que puede tener la empresa que utilice este
Proyecto. Para ello, Mininet nos ofrece la interfaz gráfica con funcionalidades para añadir y eliminar
switches y hosts, pero sin tener la posibilidad de definir características de los enlaces o direcciones
IP.
Para poder definir las características de nuestra red, tendremos que crear scripts Python utilizando
la librería que nos ofrece Mininet para esto.
De la interfaz gráfica a la que hemos aludido podemos obtener el código que genera y así
familiarizarnos con las opciones sencillas, antes de ampliarlas a opciones más complejas. Lo que
queda claro es el esquema y orden de tareas en el que hay que crear el script:
1. Creación de la red.
2. Designación de una controladora.
3. Creación de switch.
4. Creación de host.
5. Creación de enlaces.
2.6.1.3 Conexión entre Mininet y OpenDayLight.
En esta parte del Proyecto, nos volvemos a encontrar otra serie de problemas que dificultan su
avance. Estos problemas nos los encontramos a la hora de conectar la red virtual creada mediante
Mininet y nuestra controladora OpenDayLight.
Es necesario estar seguros del inicio correcto del servicio de OpenDayLight, no vale sólo con que el
estado sea iniciado. Este, a veces, tiene una demora mayor a la usual. Un motivo de este retraso es
28 OmniController | Ledo Guede, Nerea
el sucesivo reinicio del servicio y/o topologías asociadas, y para su solución hay que reiniciar el
servidor. Si el inicio no es correcto, al comenzar la red virtual mediante Mininet, aparece un reporte
de la conexión no correcta con la controladora.
Al acceder a la interfaz Dlux, el resultado que se obtiene es el mismo que nos ocurría con la red real.
Contando que se ha instalado Mininet a través de la máquina virtual que se ofrece en su propia
página oficial, que se ha dispuesto de configuración necesaria (la recomendada por su sencillez para
iniciarnos con esta herramienta), realizamos los siguientes cambios de configuración:
- Como la controladora OpenDayLight está instalada en el servidor de la empresa, se instala
en una máquina virtual (en VirtualBox) para así descartar fallo en las conexiones, teniendo
control total al estar configuradas en modo puente.
- Se instala Mininet de forma nativa, a través de la descarga y compilación de su código que
podemos encontrar en Git, en el mismo servidor que tenemos OpenDayLight. Así, se evita
todos los fallos de configuraciones de red al tener todas las herramientas necesarias en la
misma máquina.
- Para verificar que el problema no proviene de la versión Helium de OpenDayLight, se instala
la versión Base de OpenDayLight. Nos ofrece menos herramientas y plug-ins, pero su
funcionamiento es similar.
Tras estos cambios el nuevo entorno tampoco nos permite visualizar la topología de la red.
2.6.1.4 Solución para continuar con el desarrollo del Proyecto.
Después del estudio e instalación de las diversas opciones de configuración comentadas en el
apartado anterior se decidió cambiar a la distribución Ubuntu 14.04.
Las primeras pruebas se realizaron con la versión Desktop (versión de escritorio) debido a que es la
utilizada en las experiencias citadas anteriormente. Al conseguir el funcionamiento correcto (se
visualiza la topología en la interfaz gráfica Dlux), y entender que no hay diferencias en el núcleo del
sistema operativo con la versión Server (versión de servidor), se decidió cambiar a este sistema ya
que era la idea de nuestra maqueta, pensada para la facilidad de instalación y uso del usuario final.
Finalmente, los pasos a seguir para el correcto funcionamiento son:
1- Descarga, instalación y configuración de JVM 1.7.
2- Descarga, instalación y configuración de OpenDayLight (versión Helium Sr3).
3- Descarga e instalación de Mininet a través de código nativo.
Por nuestra experiencia, y después de resolver algunos fallos de instalación (instalación de paquetes
por separado, por ejemplo) recomendamos realizar una recuperación de espacio libre (con el
comando “sudo apt-get autoclean”)
2.7 Prueba de funcionamiento. Para probar el funcionamiento de la conexión entre Mininet y OpenDayLight, tras tener iniciado el
servicio de OpenDayLight, ejecutamos un script Python de creación de red. En la herramienta
Mininet hay que verificar el funcionamiento correcto de los enlaces (conocido en el mundo de las
redes “hacer un ping”) para que exista tráfico por el que la controladora OpenDayLight reconozca los
29 Ledo Guede, Nerea | OmniController
dispositivos de la red. Así, al acceder a la interfaz gráfica Dlux, podemos observar la topología de la
red.
En la imagen siguiente, podemos observar (como ejemplo) una red de 3 switch con 1 hosts cada uno.
Por ilustrar el contenido de un tal script Python de creación, mostramos el código del
correspondiente a la topología de la figura anterior:
#!/usr/bin/python
#Autor: Nerea Ledo Guede
from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSController
from mininet.node import CPULimitedHost, Host, Node
from mininet.node import OVSKernelSwitch, UserSwitch
from mininet.node import IVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info
from mininet.link import TCLink, Intf
from subprocess import call
def myNetwork():
net = Mininet( topo=None,
listenPort=6634,
build=False,
ipBase='10.0.0.0/8',
link=TCLink)
info( '*** Adding controller\n' )
c0=net.addController(name='c0',
controller=RemoteController,
protocol='tcp', protocols='OpenFlow13',
ip='127.0.0.1' #porque está en misma maquina
)
info( '*** Add switches\n')
s3 = net.addSwitch('s3', cls=OVSKernelSwitch,
mac='00:00:00:00:00:06', protocols='OpenFlow13')
30 OmniController | Ledo Guede, Nerea
s2 = net.addSwitch('s2', cls=OVSKernelSwitch,
mac='00:00:00:00:00:05', protocols='OpenFlow13')
s1 = net.addSwitch('s1', cls=OVSKernelSwitch,
mac='00:00:00:00:00:04', protocols='OpenFlow13')
info( '*** Add hosts\n')
h3 = net.addHost('h3', cls=Host, ip='10.0.0.3',
defaultRoute=None, mac='00:00:00:00:00:03')
h2 = net.addHost('h2', cls=Host, ip='10.0.0.2',
defaultRoute=None, mac='00:00:00:00:00:02')
h1 = net.addHost('h1', cls=Host, ip='10.0.0.1',
defaultRoute=None, mac='00:00:00:00:00:01')
info( '*** Add links\n')
net.addLink(s2, s1, bw=10, delay='0.2ms')
net.addLink(s2, s3, bw=10, delay='0.2ms')
net.addLink(s3, s1, bw=10, delay='0.2ms')
net.addLink(s3, h3, bw=10, delay='0.2ms')
net.addLink(s2, h2, bw=10, delay='0.2ms')
net.addLink(s1, h1, bw=10, delay='0.2ms')
info( '*** Starting network\n')
net.build()
info( '*** Starting controllers\n')
for controller in net.controllers:
controller.start()
info( '*** Starting switches\n')
net.get('s3').start([c0])
net.get('s2').start([c0])
net.get('s1').start([c0])
info( '*** Post configure switches and hosts\n')
CLI(net)
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
myNetwork()
31 Ledo Guede, Nerea | OmniController
Capítulo 3 – Replanteamiento de objetivos
Como se ha visto en el Capítulo 2, se han encontrado numerosos problemas técnicos que han
obligado a replantear el Proyecto tal cual se pensó en un primer momento.
3.1 Motivos del replanteamiento Tras realizar correctamente las configuraciones de la maqueta, cambiar algunas de las características
de dicha maqueta, e incluso, tras contar con la ayuda de la empresa que ha propuesto este TFG
(Masscomm Innova), vemos la imposibilidad de uso de la maqueta inicial propuesta.
Tras realizar el estudio correspondiente, como se ha expuesto en el Capítulo 2, hemos encontrado la
herramienta Mininet, que nos da la posibilidad de continuar el Proyecto. Dicha herramienta la
hemos localizado buscando soluciones a los errores encontrados con la utilización de nuestra
maqueta, y está siendo utilizada por usuarios que estudian las capacidades de OpenDayLight.
Con ello, si en vez de utilizar una red real, utilizamos una red virtual, creada mediante la herramienta
Mininet, la controladora OpenDayLight funciona correctamente.
3.2 Replanteamiento de objetivos El Proyecto sigue manteniendo su objetivo principal, facilitar a los administradores de redes su
trabajo en cuanto a la red de su empresa. Aunque las pruebas que nosotros vamos a realizar no
serán con una red real, su traslado a una de ellas debería realizarse sin apenas trabajo y
contratiempos, además, su uso sería equivalente.
Por razones obvias, desaparece la funcionalidad planteada de poder realizar un bypass a un firewall
si este falla, ya que la herramienta Mininet no nos ofrece la posibilidad de incorporar a nuestra red
este tipo de hardware o software.
Además, descartamos la idea de crear una aplicación web con HTML-5 por el tiempo necesario para
ello, dejando que nuestra aplicación sea manejada a través de la consola Ubuntu Server.
El resto de objetivos planteados, siguen siendo objetivos a cumplir en esta parte del Proyecto.
Al realizar las pruebas con una red virtual, se pretende no depender de la marca del hardware que
componga la red, sino que el funcionamiento sea independiente de fabricantes.
Aunque se han descartado algunos objetivos iniciales, algunas tareas se han incrementado, debido al
uso y aprendizaje de nuevas tecnologías con redes:
- Por un lado, ha sido necesario hacer comprobaciones y cambios de configuraciones en la
maqueta inicial, a más bajo nivel para averiguar el fallo del no funcionamiento óptimo.
- Por otro lado, ha sido necesario estudiar la nueva herramienta Mininet y herramientas
relacionadas.
- Para finalizar, no solo se va usar el lenguaje JSON, sino también XML para la comunicación
entre la controladora OpenDayLight y las componentes de ella que son necesarias. De
nuevo, esto ha supuesto un incremento de horas de estudio.
32 OmniController | Ledo Guede, Nerea
3.3 Nuevo objetivo Como nuevo objetivo del Proyecto, nos planteamos, desarrollar una aplicación que permita al
administrador de red de una empresa realizar, de una manera razonablemente amigable, las
siguientes acciones:
- crear redes lógicas independientes desde una misma red física (VLAN).
- activar filtros para defenderse de los ataques de denegación de servicio (DDoS).
- detectar determinados tráficos y cambiar su prioridad
- realizar envío de información en múltiples redes a múltiples destinos simultáneamente. Esto
se haría realizando multicast (multidifusión) a través de SDN.
- mostrar estadísticas de la red.
La aplicación desarrollada interactuará con el usuario a través de la consola de Ubuntu.
La siguiente figura muestra el nuevo esquema de la aplicación tras los cambios realizados, en ella
podemos ver que:
- el entorno virtual se reduce a un único servidor, donde se ejecutará la controladora
OpenDayLight y la aplicación Python.
- el entorno Mininet es la red virtual creada con la herramienta.
- los lenguajes de comunicación entre la controladora OpenDayLight y la red virtual son JSON
y XML.
33 Ledo Guede, Nerea | OmniController
Capítulo 4 – Desarrollo de la aplicación
Este capítulo tratará las diferentes funcionalidades de la aplicación desarrollada. Habrá una pequeña
explicación sobre qué herramienta de OpenDayLight se ha utilizado (si es el caso), cómo ha sido
desarrollada la parte de la aplicación y qué datos son necesarios para su utilización.
4.1 Modificar flujo en la red En este apartado, vamos a explicar cómo se puede añadir flujo a nuestra red mediante API REST en
OpenDayLight. En la primera maqueta de este Proyecto, el lenguaje a utilizar era JSON, pero debido
a la información encontrada sobre la librería y estructuras a utilizar, se ha decidido usar XML, ya que
está mucho más documentada la forma de emplearlo en este contexto.
4.1.1 ¿Qué necesitamos?
Para la creación de flujos en una red a través de OpenDayLight no es necesario instalar o configurar
ninguna característica adicional.
Lo único que necesitamos (por medio de comandos de consola en el servidor en que tenemos
instalado OpenDayLight) es enviar, a través de HTTP, datos en formato XML. Estos datos indican a la
controladora los campos necesarios para su ejecución.
El fichero XML contiene una serie de instrucciones, donde cada instrucción debe tener asignado un
orden de prioridad y define qué tipo de acciones se van a aplicar. A continuación, el fichero
incorpora la información de la tabla de enrutamiento a la que pertenece y de cuál es el identificador
del filtro. Por último, se debe indicar cuál es la característica que se quiere filtrar.
4.1.2 ¿Qué características podemos elegir?
Cinco son las características que podemos elegir:
1- Dirección MAC de origen.
2- Dirección MAC de destino.
3- Dirección IP de origen.
4- Dirección IP de destino.
5- TCP DPORT: puerto destino del tráfico.
Estas características las podemos elegir solas o cumpliendo alguna de las siguientes parejas:
a- Dirección MAC origen y dirección MAC destino.
b- Dirección IP origen y dirección IP destino.
4.1.3 ¿Qué acciones se pueden llevar a cabo?
Dos son las acciones que podemos elegir para nuestra regla de flujo:
1- Puerto del switch por el que va pasar el tráfico.
2- Borrar el tráfico, es decir, que no llegue al dispositivo destino.
34 OmniController | Ledo Guede, Nerea
4.1.4 ¿Qué se puede hacer con las reglas de flujo?
Dos son las opciones que podemos hacer:
1- Introducir regla en la controladora OpenDayLight. Para ello, aparte de usar un fichero XML
como hemos comentado anteriormente, tenemos que indicar a qué switch hace referencia
esta regla, en qué tabla la vamos a poner y cuál es el identificador de la regla.
2- Eliminar regla en la controladora OpenDayLight. Para ello solo necesitamos saber a qué
switch hace referencia la regla a borrar, en qué tabla está y cuál es el identificador de dicha
regla.
4.1.5 ¿Cómo usa el usuario final esta parte de la aplicación?
Cuando el usuario acceda a la opción flujo en el menú principal, le saldrán dos opciones:
1. Crear flujo
2. Borrar flujo
4.1.5.1 Crear flujo como usuario de la aplicación
Siendo la opción elegida crear flujo, el usuario siempre tendrá que introducir el número de
identificador del switch al que le quiera insertar la regla de flujo, además, el identificador de la tabla
donde se va a incorporar la regla y, un identificador para la regla (para referirnos a ella en futuras
opciones).
Después de estos datos tendrá que elegir entre las siguientes opciones de características para
nuestra regla:
a. Dirección MAC: a continuación tendrá la opción de elegir si quiere insertar la dirección
origen y/o dirección destino e insertar las direcciones que crea oportunas.
b. Dirección IP: como en el caso anterior tiene que elegir entre dirección origen y/o dirección
destino e introducirlas.
c. TCP Dport: el usuario tendrá que insertar el número de puerto al que va dirigido el tráfico
que quiere modificar.
Tanto las direcciones IP, como las direcciones MAC pueden no encontrarse en la red en el momento
que creamos la regla de flujo, ya que los dispositivos se pueden conectar con posterioridad y cumplir
la regla de flujo creada anteriormente.
A continuación, con cualquiera de las tres opciones anteriores, el usuario tendrá que elegir entre las
dos acciones que se pueden llevar a cabo:
1) Puerto del switch al que redireccionar el tráfico.
2) Borrar el tráfico.
4.1.5.2 Borrar flujo como usuario de la aplicación
Si en el menú de flujo elegimos borrar flujo como opción, el usuario tiene que introducir el
identificador del switch, además, el identificador de la tabla donde está la regla y, el identificador de
la regla.
35 Ledo Guede, Nerea | OmniController
Si el usuario quiere comprobar la correcta instalación de estas reglas y el buen funcionamiento,
tiene que comprobarlo en el propio switch. En nuestro caso lo probamos con Mininet a través del
comando “sh ovs-ofctl –O OpenFlow13 dump-flows s1” (siendo s1 el identificador del switch), ya que
esta herramienta no nos permite realizar la comprobación de otra forma, si no es a través de su
consola.
4.2 Creación de subredes La creación de redes lógicas independientes desde una misma red física, es uno de los objetivos de
este Proyecto. En el Capítulo 2, hemos visto que OpenDayLight nos ofrece varias herramientas y/o
plug-ins para ello. Nosotros destacamos dos:
1. VTN
2. SNMP4SDN
Hay dos diferencias importantes entre ellas:
a- VTN está desarrollada para redes más complejas que SNMP4SDN.
b- SNMP4SDN utiliza el protocolo SNMP mientras que VTN utiliza API REST.
4.2.1 Subredes con VTN (Virtual Tenant Network)
El proyecto VTN está compuesto de una herramienta y de un plug-in, ambos necesarios. La
herramienta, VTN Coordinator, es la responsable de la virtualización de las subredes y es externa a
OpenDayLight. El plug-in, VTN Manager, interno en OpenDayLight, se comunica a través de la API de
VTN con la herramienta anterior para crear, modificar y borrar componentes en la red.
VTN Coordinator tiene que ejecutarse en una máquina diferente a la controladora, por ello hay que
instalar un servidor Ubuntu Server 14.04 (VTN Coordinator, soporta cualquier plataforma Linux de
64 bits) y los paquetes previos necesarios. Entre ellos destacamos:
- GCC: compilador que utiliza la herramienta.
- Maven: plug-in Apache para instalar proyectos Java.
- Xmlstarlet y Json: plug-ins para la utilización de los lenguajes.
- Openssl: proyecto de Software para añadir seguridad a la herramienta.
- Openjdk-7-jdk: paquete que contiene la versión libre de Java.
- PostgreSQL: base de datos necesaria para el funcionamiento de la herramienta.
Después de las configuraciones previas, hay que descargar el código de VTN Coordinator para su
construcción e instalación. Tras estas tareas, el servicio se inicializa o para ejecutando los comandos
vtn_start y vtn_stop, que encontramos como variables locales en la carpeta /usr/local/vtn/bin.
Tras comprobar el funcionamiento correcto y la comunicación entre VTN Coordinator y VTN
Manager, para obtener mayor nivel de seguridad, se puede activar el Firewall predeterminado a
través de certificados de identidad firmados y también los certificados generadores en el servidor
web, como indica la documentación de OpenDayLight. A partir de este momento, la conexión desde
el cliente cambia de protocolo, de HTTP a HTTPS.
36 OmniController | Ledo Guede, Nerea
Por su parte, el plug-in VTN Manager se instala en OpenDayLight a través de características de la
consola Karaf.
Para comprobar el buen funcionamiento, es necesario tener el servicio de VTN Coordinator activado
y, desde la máquina de OpenDayLight, establecer conexiones a través de VTN API REST y comandos
curl (llamadas a url) al otro servidor.
Estos comandos, para nuestro usuario final, no son necesarios ya que los realiza nuestra aplicación;
pero tiene que tener claro las siguientes tareas, que sí son necesarias:
1. Creación de un controlador: este controlador le da a VTN Coordinator la información
necesaria de nuestra red, además de una dirección IP para poder conectarse y comunicarse
con los switches.
2. Creación de un gerente de redes virtuales: este gerente es el encargado de crear y
comunicar los puntos siguientes.
3. Creación de un puente virtual: necesitamos crear uno para cada subred que queremos crear
en el siguiente punto.
4. Creación de subred: este punto es la creación de la propia red, tiene que crearse con
referencia a un puente virtual creado con anterioridad.
4.2.2 SNMP4SDN
En un principio, SNMP4SDN fue la herramienta que habíamos decidido utilizar, por los siguientes
motivos:
- Porque nos permite conocer cómo OpenDayLight se comunica a través de SNMP. De este
modo, podremos compararlo con el uso que realizan diversas herramientas software de
Alcatel-Lucent; concretamente, en su comunicación a través del mismo protocolo (SNMP)
con switches de la misma marca (Alcatel-Lucent).
- Porque nos obliga a trabajar con diversos formatos de comunicación de OpenDayLight (otras
herramientas trabajadas solo utilizan API REST).
- Porque SNMP4SDN está desarrollada para redes que no sean de gran tamaño y complejidad,
como es el caso de nuestra maqueta.
Pero, al consultar las configuraciones necesarias tal y como aparecen en la documentación sobre el
proyecto en la wiki de OpenDayLight, se comprueba que hay que modificar el fichero de la base de
datos y cargarla en el switch a través de la consola Karaf. Este último paso nos ha hecho cambiar de
herramienta de OpenDayLight (utilizamos VTN como hemos comentado en el apartado anterior),
porque no ha sido posible realizarlo por los siguientes motivos:
- Desconocemos el modelo de datos de la base de datos y no encontramos documentación
apropiada (se dispuso de un ejemplo de fichero en formato txt con un conjunto de datos,
semejante a una tabla, pero sin detalles de cómo hacerlo).
- Cargando el ejemplo de tabla o fichero txt con los datos en la forma que nos pareció más
apropiada, la consola Karaf nos dio un fallo en el formato de datos.
37 Ledo Guede, Nerea | OmniController
Tras la búsqueda de información, ejemplos y experiencias personales, no encontramos datos
coherentes en nuestra instalación.
4.2.3 ¿Cómo utiliza el usuario final esta parte de la aplicación?
Al elegir la opción VLAN del menú principal nos sale, otro menú donde podemos elegir:
1. Crear VLAN
2. Eliminar VLAN
3. Listar VTN
4.2.3.1 Crear VLAN como usuario
Al acceder a crear VLAN la aplicación nos muestra un recordatorio de los pasos a seguir:
a. Crear un controlador. Si este nunca ha sido creado anteriormente o si queremos tener más
de uno. Al usuario se le pedirá la IP con la que quiera que el controlador trabaje, por
ejemplo, 10.0.0.2 y, además, el identificador de dicha controladora.
b. Crear VTN. Va asociada a una controladora, por lo que es necesario que el usuario indique a
cuál está asociada a través del identificador del controlador. También, tiene que introducir el
nombre de la VTN y una breve descripción.
c. Crear VLAN y vBridge asociado. En este paso, es necesario que el usuario indique el
identificador del controlador y de la VTN. Además, indicar el identificador que va a tener el
vBridge y la VLAN
La VLAN tiene que ser identificador numérico mientras que el resto de identificadores son
alfanuméricos.
4.2.3.2 Eliminar VLAN como usuario
Para realizar la opción de eliminar VLAN, el usuario tiene que introducir en la aplicación el
identificador de la VLAN que quiere eliminar, el identificador de vBridge al que pertenece y el
identificador de la VTN correspondiente.
4.2.3.3 Listar VTN como usuario
Si el usuario elige la opción listar VTN, solo es necesario que introduzca el identificador de la VTN
que quiera información.
4.3 Estadísticas de la red. Otro de los objetivos del Proyecto es acceder a diferentes estadísticas de nuestra red.
La aplicación, al elegir alguna de las opciones que detallamos a continuación, nos mostrará una
dirección web (que corresponde a la interfaz gráfica de la controladora OpenDayLight) a la que el
usuario tiene que acceder para verlas.
Las estadísticas que el usuario puede elegir, siendo todas ellas de un nodo específico de la red, son:
1. Estadísticas de flujo agregado y estadísticas de tablas de flujo.
2. Estadísticas de flujos individuales desde tabla específica.
38 OmniController | Ledo Guede, Nerea
3. Grupo de características y estadísticas de características de una regla.
4. Descripción de grupos y estadísticas de grupos.
5. Configuración de regla y estadísticas de regla.
6. Estadísticas del nodo conector.
7. Estadísticas de cola.
La construcción de la funcionalidad se limita a la configuración de la controladora para hacer visibles
esas direcciones y datos.
4.4 Detección de ataques de denegación de servicios Uno de los objetivos planteados en este Proyecto es detectar ataques de denegación de servicios.
Para ello, como hemos comentado en el Capítulo 2, OpenDayLight tiene una herramienta,
Defense4all, que los detectará.
Este objetivo, no ha podido ser cumplido en el Proyecto.
Al querer instalar Defense4All en una máquina diferente a la controladora OpenDayLight, con la que
se comunicará a través de llamadas API REST, nos encontramos una serie de problemas:
- El enlace de descarga de la documentación no funciona. Por ello, buscamos en el repositorio
Jenkins este proyecto (lugar referido en el enlace de descarga), pero tampoco podemos
descargarlo. Tras buscar información, encontramos los módulos de la versión estable para
Helium en el repositorio Git.
- Al instalar (a través de Maven) el módulo principal, según la información encontrada, nos da
error de dependencias. Instalando por separado los módulos solucionamos estos fallos.
- En las instalaciones, nos encontramos errores como que la variable de entorno java_home
no tiene el paquete de herramientas correspondiente, también errores tras ejecutar
instrucciones no admitidas. Estos se solucionan instalando los paquetes Ubuntu necesarios.
Tras instalar todos los módulos correctamente, no se ha conseguido inicializar el servicio de la
herramienta, ya que este no es reconocido por el comando de inicialización (el servicio no aparece
en las listas del sistema).
Para buscar solución sobre la inexistencia del servicio, accedemos al log del repositorio Jenkins
donde están trabajando en las diferentes versiones del software. Observamos en él fallos muy
recientes (incluso de hoy mismo), tanto de compilación como de ejecución. Además, la versión
utilizada por nosotros, descargada del repositorio Git (único enlace disponible al recurso), es la más
reciente en este, pero es más antigua que las versiones de Jenkins (repositorio principal, ya que la
guía de instalación hace referencia a él con un enlace a un recurso no disponible). Por lo tanto,
opinamos, que en esta versión descargada falta alguna directiva que establezca el servicio. Regla que
nosotros no podemos incorporar a los ficheros de instalación por el desconocimiento del núcleo
interno de OpenDayLight.
39 Ledo Guede, Nerea | OmniController
4.5 Multicast en OpenDayLight Uno de los objetivos señalados para este Proyecto es poder tratar multicast en nuestra red. Tras el
estudio de la API, encontramos que OpenDayLight no ofrece todavía ningún plug-in ni herramienta
para ello. Resulta extraño que no esté realizado, dado que la implementación en las redes actuales
es más simple utilizando SDN.
No está previsto desarrollar este plug-in, ya que se sale de los objetivos de este Proyecto y no sería
realista su realización. Sin embargo, pensamos que podría ser factible haciendo visible para el
controlador el multicast, de forma que los clientes que quieran recibirlo sean conocidos también por
el controlador (se podría conectar directamente en los switch o routers intermedios mediante la
configuración de los flujos).
Además, habría que implementar el protocolo IGMP (Internet Group Management Protocol,
utilizado para intercambiar información acerca del estado de pertenencia entre enrutadores IP que
admiten multidifusión y miembros de los grupos). La implementación se podría realizar a través de
reglas, para que el controlador pueda saber qué clientes están en el grupo de multicast. Además,
habría que configurar los puertos de este protocolo y los grupos de OpenFlow para cada grupo de
multicast conocido por el controlador.
4.6 Maqueta con herramientas para el usuario Para el buen funcionamiento de la aplicación desarrollada en este Proyecto, el usuario necesita
contar con:
- Un entorno virtual compuesto por tres servidores.
1. El servidor donde está configurado OpenDayLight (servidor con nombre ODL).
2. El servidor que contiene la herramienta VTN Coordinator
3. El servidor que contiene la herramienta Defense4all.
- Una red virtual creada con la herramienta Mininet.
40 OmniController | Ledo Guede, Nerea
La maqueta siguiente muestra la composición del escenario propuesto para que la aplicación
funcione correctamente:
41 Ledo Guede, Nerea | OmniController
Capítulo 5 – Gestión de Proyecto
En el Capítulo 1 hicimos la planificación estimada por semanas. En este capítulo observamos, a la
finalización del Proyecto, la diferencia entre el tiempo de trabajo planificado para cada tarea y el
tiempo de trabajo real.
5.1 Planificación inicial Este Proyecto estaba previsto que durara desde el 1 de febrero hasta el 1 de junio de 2015, teniendo
un hito principal cada mes, con un total de aproximadamente 300 horas.
El Proyecto se dividió en semanas, pero las tareas fueron descritas mensualmente.
Tarea Semana 4
23/2-1/3
Semana 9
30/3-5/4
Semana 13
27/4-3/5
Semana 17
25/5-31/5
Maqueta
configurada
Estudio de
Python y JSON
Estudio API
OpenDayLight
AOS
App Python
App web
Piloto finalizado
App Android e
iOS
Proyecto
finalizado
Memoria
finalizada
42 OmniController | Ledo Guede, Nerea
5.2 Planificación final El Proyecto, se inició en la fecha prevista, pero su finalización se retrasó tantas semanas como
teníamos de margen hasta la entrega, quedando la configuración mensual de tareas de la siguiente
forma.
Tarea Semana 4
23/2-1/3
Semana 9
30/3-5/4
Semana 13
27/4-3/5
Semana 17
25/5-31/5
Semana 21
22/6-28/6
Maqueta
configurada
Estudio de
Python y JSON
Estudio API
OpenDayLight
AOS
App Python
App web
Piloto finalizado
App Android e
iOS
Proyecto
finalizado
Memoria
finalizada
Estudio de la
herramienta
Mininet
Estudio de XML
43 Ledo Guede, Nerea | OmniController
Las tareas marcadas con “”, fueron tareas descartadas a la hora de cambiar los objetivos al pasar
de maqueta con red real a maqueta con red virtual.
La media de horas realizadas por semana en el proyecto se mantuvo en 17, contando que se amplió
el Proyecto 4 semanas, el total de horas realizadas han sido 357.
En la siguiente lista de tareas se explicarán los motivos de los retrasos en cada una de las tareas de la
tabla:
- Maqueta configurada: esta tarea no ha sido ejecutada según su planificación inicial. El
primer retraso fue la demora en la llegada del hardware necesario, lo que permitió adelantar
la tarea “AOS”. El segundo motivo, el cual fue crucial, fueron los problemas con el
funcionamiento adecuado de la maqueta de red real con la controladora OpenDayLight.
Cuando nos referimos a la finalización de esta tarea, hacemos referencia a la maqueta
configurada en una red virtual creada con Mininet.
- Estudio de Python y JSON: esta tarea se cumplió en plazo. Sin embargo, no debemos
olvidarnos de que ha sido necesario realizar un estudio más profundo a la hora de abordar
temas más concretos sobre estos lenguajes.
- Estudio API OpenDayLight: tarea cumplida según la estimación.
- AOS: esta tarea, por desviaciones a la hora de disponer del hardware, fue adelantada en
plazo.
- App Python: tal y como se ha comentado previamente en el Capítulo 3, los objetivos
funcionales de la aplicación sufrieron cambios. Tras la demora de la maqueta, la tarea se
inició con retraso. A su vez, al encontrarnos con herramientas beta, fue necesaria una
ampliación de tiempo. Esto se debe a la poca información disponible y otros problemas ya
comentados a lo largo de la memoria.
- App web: como dijimos en el Capítulo 3, esta tarea dejó de formar parte de los objetivos
finales del Proyecto.
- Piloto finalizado: al retrasarse la tarea App Python y, además del tiempo añadido de
realización de las pruebas, esta tarea se retrasó en el tiempo. Sin embargo, no causó
problemas significativos en su desarrollo.
- App Android e iOS: al igual que la aplicación web, esta tarea fue descartada de los objetivos
finales.
- Proyecto finalizado: después del retraso de la tarea “Piloto finalizado”, las pruebas
definitivas y las muestras de la aplicación a la empresa y al tutor también fueron retrasadas.
- Memoria finalizada: la realización de la memoria del Proyecto debe finalizar al mismo
tiempo que este, lo que ha supuesto no poder finalizar este documento hasta la última
semana.
Por último enumeramos las tareas desarrolladas en el Capítulo 3 de la memoria. Estas han supuesto
un retraso generalizado en las anteriores. Las tareas a las que nos referimos son:
44 OmniController | Ledo Guede, Nerea
- Estudio de la herramienta Mininet
- Estudio del lenguaje XML
Cabe destacar el estudio más profundo de las herramientas de OpenDayLight, en respuesta a los
fallos encontrados a lo largo de sus procesos de instalación y configuración. Esto ha supuesto un
incremento de horas de trabajo en el Proyecto, además de un retraso en la tarea “App Python” y
sucesivas.
5.3 Resumen En este epígrafe resumimos los motivos principales del retraso sufrido en el Proyecto. Nos hemos
encontrado numerosos errores entre los que podemos destacar:
- Errores en la configuración de la maqueta real, lo que supone la imposibilidad de hacer uso
de ella.
- Errores en la transición de maqueta real a maqueta virtual. Para conseguir su
funcionamiento, ha sido necesario un cambio de versión del sistema operativo.
- Errores en las herramientas de la controladora OpenDayLight necesarias. Este error ha
supuesto la imposibilidad de desarrollar alguna de las funcionalidades.
Estos errores también hicieron que fuera necesario más tiempo de estudio sobre herramientas
necesarias para el Proyecto.
45 Ledo Guede, Nerea | OmniController
Capítulo 6 – Conclusiones y futuras mejoras.
6.1 Conclusiones El resultado del Proyecto, en cuanto a funcionalidades de la aplicación final, no alcanza los objetivos
iniciales; en contraposición, el aprendizaje sobre redes, SDN, OpenFlow, y la controladora
OpenDayLight supera las expectativas.
Tengo que destacar la importancia de que en un proyecto es necesario el trabajo en equipo. En este
caso, esto no ha sido posible ya que se trata de un trabajo personal (TFG), pero debido a la
complejidad en determinados puntos del Proyecto he tenido expertos de la empresa Masscomm
Innova a mi lado, a los que agradezco enormemente su atención y colaboración.
Una vez finalizado el Proyecto, me he dado cuenta del error cometido al no realizar una gestión de
proyecto correcta. Error cometido, al no volver a calcular el tiempo necesario cuando se decidió
cambiar los objetivos del Proyecto.
Por último, si en vez de ser un TFG hubiese sido un proyecto real dentro de una empresa, es claro
que no se hubiera llevado a cabo. Antes de aceptarlo, hubiera sido necesario realizar un estudio más
exhaustivo de herramientas del que he llevado a cabo en la primera fase del Proyecto y, al ver que
gran parte de ellas están todavía en desarrollo, se hubiese planteado como un proyecto inviable. En
caso de que en dicho estudio no se hubiera visto lo anterior, una vez que se llegara a no poder
realizar el proyecto en una maqueta real, también hubiera sido descartado, al no tener sentido
realizar una aplicación para una red virtual.
6.2 Futuras mejoras Una posible mejora, sería realizar la aplicación web que nosotros hemos sacado de nuestros
objetivos. Incluso, como fue propuesto por la empresa, realizar las aplicaciones móviles, pero no solo
con las transformaciones básicas (para esto existen diversos servicios que lo realizan
automáticamente) sino, realizándola desde cero adaptada a nuestros objetivos.
En el momento en que nuestra aplicación pueda ser comprobada con una red real, realizar el
objetivo eliminado de creación de un bypass a un firewall.
Añadir funcionalidades como pueden ser:
- Funcionalidad básica para switch de conmutación de capa2 (L2 switch). Además,
proporcionar servicios ejemplares para esta funcionalidad como:
1. Seguimiento de direcciones
2. Cálculo de rutas óptimas para los paquetes
3. Llevar a cabo el protocolo de árbol de expansión básico a fin de impedir colapso en
la red.
- Incluir la posibilidad de crear red enrutada privada virtual (L3VPN).
46 OmniController | Ledo Guede, Nerea
47 Ledo Guede, Nerea | OmniController
Bibliografía
Introducción
http://www.ontsi.red.es/ontsi/es/indicador/empresas-con-conexi%C3%B3n-internet
Datos estadísticos sobre conexión a internet en empresas.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Comparativa de lenguajes de programación.
Terminología
https://www.opennetworking.org/
Página principal Open Networking Foundation.
https://gigaom.com/2013/01/30/sdn-is-not-openflow-but-openflow-is-a-real-disruption/
Diferencias entre SDN y OpenFlow.
http://www.opendaylight.org/
Página principal del proyecto OpenDayLight.
http://www.opendaylight.org/project/technical-overview
Características técnicas de OpenDayLight.
API OpenDayLight
https://wiki.opendaylight.org/view/Main_Page
Wiki oficial de OpenDayLight: Página principal.
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Main
Wiki oficial de OpenDayLight: Proyecto OpenFlow Plugin.
https://wiki.opendaylight.org/view/OpenDaylight_dlux:Main
Wiki oficial de OpenDayLight: Proyecto Dlux.
https://wiki.opendaylight.org/view/Defense4All:Main
Wiki oficial de OpenDayLight: Proyecto Defense4All.
https://wiki.opendaylight.org/view/SNMP4SDN:Main
Wiki oficial de OpenDayLight: Proyecto SNMP4SDN.
https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Main
Wiki oficial de OpenDayLight: Proyecto Virtual Tenant Network.
48 OmniController | Ledo Guede, Nerea
https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)
Wiki oficial de OpenDayLight: Proyecto Group Based Policy.
https://wiki.opendaylight.org/view/YANG_Tools:Main
Wiki oficial de OpenDayLight: Proyecto YANG Tools.
Mininet
http://mininet.org/
Página principal de Mininet.
http://mininet.org/download/
Versiones, tutorial de descarga y enlaces a repositorios.
http://mininet.org/walkthrough/
Pasos a seguir para implementar Mininet
http://mininet.org/sample-workflow/
Caso de uso de Mininet
Anexo 1 – Instalación OpenDayLight
OmniController Infraestructura coordinada SDN y OpenFlow
Autor:
Nerea Ledo Guede Tutor:
Laureano Lamban Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática Dpto. Matemáticas y Computación
Grado en Ingeniería Informática Universidad de La Rioja
Curso académico 2014/2015
Logroño, La Rioja
Anexo 1 – Instalación OpenDayLight
En este anexo podemos ver los pasos a seguir para la instalación de OpenDayLight Helium SR3.
También son válidos para la versión Helium SR2.
1- Descargamos el fichero de la página oficial:
wget
https://nexus.OpenDayLight.org/content/groups/public/org/OpenDayLight/integration/distrib
ution-karaf/0.2.3-Helium-SR3/distribution-karaf-0.2.3-Helium-SR3.tar.gz
2- Descomprimimos el fichero descargado:
tar -xzvf distribution-karaf-0.2.2-Helium-SR3.tar.gz
3- Entramos en la carpeta que acabamos de descomprimir, subdirectorio bin:
cd distribution-karaf-0.2.2-Helium-SR3/bin
4- Nos encontramos con varios módulos ejecutables:
./karaf → línea de comandos de OpenDayLight (*Fallo 1)
./shell→ línea de comandos de Karaf
./start → iniciar proceso
./status → ver el estado del proceso
./stop → parar proceso
5- Ahora ponemos en marcha la interfaz de usuario, para ello es necesario acceder a la línea de
comandos de Karaf e instalar una serie de paquetes preinstalados.
./karaf
feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-Dlux-core
Para entrar en la interfaz de usuario hay que acceder a la siguiente dirección:
http://192.168.23.245:8181/Dlux/index.html (siendo 192.168.23.245 la dirección IP de nuestro
servidor y 8181 el puerto donde corre la interfaz Dlux).
Accedemos con usuario y contraseña “admin”. Al iniciar sesión, imprime por pantalla “enable to
login”. Investigamos este error y después de varias pruebas-error se soluciona. (*Fallo 2)
Fallo 1 Al ejecutar ./karaf nos da fallo con java_home, porque no lo habíamos instalado correctamente
con anterioridad y es necesario como se puede ver en los requisitos previos.
Los pasos para su correcta instalación son:
sudo add-apt-repository ppa:webupd8team/java
Si da fallo, en caso de no haber encontrado la orden, hay que instalar el siguiente paquete y
volver a ejecutar el comando anterior:
sudo apt-get install software-properties-common python-software-properties
El siguiente paso es actualizar e instalar el paquete descargado en el repositorio:
sudo apt-get update && sudo apt-get install oracle-java7-installer
Además de instalar java, es necesario configurar la ruta java_home. Para ello tenemos que
añadir al fichero /etc/bash.bashrc las siguientes líneas:
JAVA_HOME=/usr/lib/jvm/java-7-oracle
export JAVA_HOME
PATH=$PATH:$JAVA_HOME
export PATH
Fallo 2 Muestra el error “enable to login” dado que al instalar las características y escribir
incorrectamente alguna orden, se instalaron incorrectamente. Para solucionar el error se debe
eliminar los paquetes y volver a instalarlos en el orden adecuado.
Para eliminar los paquetes hay que introducir el siguiente comando en la consola de Karaf:
Y, por último, introducir el comando de instalación de los paquetes:
Comentarios de uso para el usuario Para el funcionamiento de la controladora OpenDayLight, es necesaria la inicialización del
servicio (./start en la carpeta bin descargada).
Para comprobar que se ha iniciado el servicio correctamente, entramos en la interfaz Dlux, en la
que pueden suceder dos cosas:
1. Accede correctamente, por lo tanto, el servicio esta inicializado.
2. No accede correctamente, en el navegador aparece el error 404 (not found).
Desconozco el tiempo de espera que necesita para iniciar correctamente. Si tarda más de lo que
creemos oportuno, podemos reiniciar el servidor que tiene instalada la controladora. Esta
demora puede ser por el reinicio continuo del servicio o por el número elevado de redes
virtuales que hemos creado y eliminado para la controladora.
Anexo 2 – OpenFlow Plug-in
OmniController Infraestructura coordinada SDN y OpenFlow
Autor:
Nerea Ledo Guede Tutor:
Laureano Lamban Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática Dpto. Matemáticas y Computación
Grado en Ingeniería Informática Universidad de La Rioja
Curso académico 2014/2015
Logroño, La Rioja
Anexo 2 – OpenFlow Plug-in
Para instalar este plug-in hay dos alternativas:
1. Utilizar el proyecto de integración.
2. Utilizar el proyecto propio openflowplugin.
Decidimos hacer la segunda instalación tras estudiar estas opciones. Para ello, hay que seguir
los siguientes pasos, en los cuales clonamos el código que se puede encontrar en git, y por último
lo construimos.
a. git clone https://git.opendaylight.org/gerrit/p/openflowplugin.git
b. cd openflowplugin
c. mvn clean install
d. cd ./distribution/karaf/target/assembly/bin/
Antes de llegar al último paso, al realizar la construcción con mvn, nos da el siguiente fallo:
[ERROR] The build could not read 1 project -> [Help 1] [ERROR]
[ERROR] The project
org.opendaylight.openflowplugin:openflowplugin-parent:0.1.0-
SNAPSHOT (/home/ops/openflowplugin/pom.xml) has 1 error [ERROR]
Non-resolvable parent POM: Could not find artifact
org.opendaylight.odlparent:odlparent:pom:1.5.0-SNAPSHOT and
'parent.relativePath' points at no local POM @ line 4, column 13
-> [Help 2] [ERROR] [ERROR] To see the full stack trace of the
errors, re-run Maven with the -e switch. [ERROR] Re-run Maven
using the -X switch to enable full debug logging. [ERROR]
[ERROR] For more information about the errors and possible
solutions, please read the following articles: [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuilding
Exception [ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMod
elException
Intentamos solucionar el problema sobre el fichero pom.xml, para ello:
- Primero buscamos el fichero pom.xml de versiones anteriores.
- A continuación comparamos el fichero que nos da error con el de las versiones
anteriores para buscar la diferencia en su dependencia.
- Por último, al no encontrar la diferencia y no poder solucionar el fallo debido a que las
soluciones encontradas son para la versión Base de OpenDayLight, decidimos instalar el
plug-in del otro modo.
Para instalar el plug-in a través del proyecto de integración, es necesario instalar los siguientes
paquetes. Se trata de paquetes pre-instalados de características en la controladora
OpenDayLight. Esto lo haremos a través de la consola Karaf.
a. feature:install odl-openflowplugin-flow-services
b. feature:install odl-openflowplugin-flow-services-rest
c. feature:install odl-openflowplugin-flow-services-ui
Estos paquetes de características instalan:
1. Servicio de OpenFlow
2. Interfaz REST necesario del servicio
3. Interfaz gráfica del servicio
Anexo 3 – Instalación Mininet y comentarios de uso
OmniController Infraestructura coordinada SDN y OpenFlow
Autor:
Nerea Ledo Guede Tutor:
Laureano Lamban Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática Dpto. Matemáticas y Computación
Grado en Ingeniería Informática Universidad de La Rioja
Curso académico 2014/2015
Logroño, La Rioja
Anexo 3 – Instalación Mininet y comentarios de uso
En este anexo se van a comentar las diversas formas de instalar la herramienta Mininet.
Además, se mostrará un pequeño manual para la creación de redes virtuales. Por último,
analizaremos diversos comandos ejecutables sobre la red, desde la consola Mininet.
Instalación Mininet Para instalar esta herramienta tenemos tres opciones:
1. Instalación de una VM con Mininet.
2. Instalación nativa con el código fuente.
3. Instalación de paquetes.
Instalación de una VM con Mininet
La página web explica que la forma más fácil para empezar es descargar la máquina virtual
Ubuntu que incluye Mininet. Esta incorpora los ficheros binarios de Openflow y herramientas
preinstaladas, además de ajustes en la configuración del kernel para soportar redes grandes.
Para esta instalación, sólo es necesario descargar la máquina virtual e instalarla a través de
cualquier herramienta que lo facilita, como por ejemplo Virtual Box.
Instalación nativa con el código fuente
Para la instalación nativa, la página oficial nos informa de que el único sistema operativo que
funciona correctamente y cuyo funcionamiento ha sido probado es Ubuntu. De forma
experimental se puede probar en Fedora.
Los pasos a seguir para la instalación son:
1. Obtener el código fuente:
git clone git: //github.com/mininet/mininet
2. Instalar Mininet:
mininet/util/install.sh [options]
Las opciones que se pueden elegir para la instalación son:
a. –a : instalar todo lo que se incluye en la máquina virtual Mininet, incluyendo
dependencias a OpenvSwitch
b. –nfv : instala Mininet y las referencias de OpenFlow a los switches
3. Comprobar que funciona con el siguiente comando:
sudo mn –test pingall
Creación de topologías Para crear topologías, nos encontramos tres modos diferentes:
- Crear topologías de forma gráfica.
- Crear topologías a través de comandos.
- Crear topologías a través de script Python.
Forma gráfica
Para entrar en la herramienta que nos ofrece la interfaz gráfica de Mininet hay que ejecutar el
script miniedit.py que nos encontramos en la carpeta examples. Una vez hecho esto, nos
aparecerá:
A través de esta herramienta, podemos explorar, añadir y eliminar switch y host. Por el
contrario, no podemos definir características de los enlaces o direcciones IP. Sin embargo, sí
que podemos exportar el código y analizarlo pacientemente para saber qué aspectos podemos
destacar y así crear con posterioridad nuestra red propia.
Línea de comandos
Para crear una red virtual sólo hace faltar escribir “sudo mn” en el terminal y nos creará una
red simple. Este comando se puede parametrizar y así añadir alguna característica en la red.
Los parámetros a destacar son:
-switch = SWITCH default|ivs|lxbr|ovs|ovsbr|ovsk|ovsl|user[,param=value…]
indicaremos el tipo de switch que queremos tener en nuestra red
-host=HOST cfs|proc|rt[,param=value…] indicaremos el tipo de host que queremos
en nuestra red
–controller=CONTROLLER indicaremos el controlador al que queremos que se
conecte, podemos indicar la IP que tiene
-topo=TOPO linear|minimal|reversed|single|torus|tree[,param=value…]
indicaremos el tipo de topología (lineal, árbol,…)
-mac establece automáticamente dirección MAC a los host de la red
Los comandos de creación de red que he estado utilizando a lo largo de este Proyecto son:
- Creación de una red simple de tres elementos, con switch de tipo ovsk. Admite
protocolo OF1.3.1 y tiene un controlador remoto con IP:
“sudo mn --topo=single,3 --mac --switch=ovsk,protocols=OpenFlow13 --
controller=remote,ip=192.168.23.245 “
- Creación de una topología de árbol con profundidad 2 y expansión 8, utiliza
interruptores vSwitch bajo la gestión de la controladora remota. Además corre el
pingall de prueba para comprobar la conectividad entre cada par de nodos.
“sudo mn --switch=ovsk --controller=remote --topo=tree,depth=2,fanout=8 --test”
Script Python
Para poder escribir un script Python, que crea una red virtual con Mininet, es necesario
familiarizarse con la librería Python que nos ofrece Mininet. Para ello, es buena idea estudiar el
código generado a través de la interfaz gráfica.
Para la creación de redes virtuales, podemos destacar:
- Importación de librerías necesarias para la creación de redes, nodos, links y
controladoras de tipo OVSC.
- Importación de librerías para ampliar los comandos disponibles de la consola Mininet,
además de la captura del log en el fichero correspondiente.
- La creación de los componentes tiene un orden específico importante:
o creación de red
o creación de controladora
o creación de switch
o creación de host
o creación de links entre dispositivos
- Por último, inicialización de la red y de los switch en ese orden.
Comandos consola Mininet A continuación, nombramos una serie de comandos para la consola de Mininet, los cuales nos
facilitarán información sobre la red virtual creada:
- help muestra los comandos de Mininet
- nodes muestra los nodos de la red
- net muestra los enlaces que se tiene en la red
- ifconfig –a muestra la configuración IP del dispositivo que se desea consultar, puede
ser un host o un switch. Ejemplo: h1 ifconfig –a donde h1 representa el host 1 en la
red.
- ps –a muestra en pantalla los procesos que se están ejecutando en la máquina.
- ping permite hacer ping entre los dispositivos de la red. Ejemplo: h1 ping h2.
- pingall prueba conectividad entre todos, es decir, hace ping entre todos los hosts.
- link [node1][node2][up or down] crea o elimina un link entre dos nodos.
Anexo 4 – Instalación Virtual Tenant Network (VTN)
OmniController Infraestructura coordinada SDN y OpenFlow
Autor:
Nerea Ledo Guede Tutor:
Laureano Lamban Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática Dpto. Matemáticas y Computación
Grado en Ingeniería Informática Universidad de La Rioja
Curso académico 2014/2015
Logroño, La Rioja
Anexo 4 – Instalación Virtual Tenant Network (VTN)
En este anexo se explicarán los pasos a seguir para la instalación de las dos componentes
necesarias para esta herramienta.
Instalación VTN Coordinator Esta herramienta tiene que estar instalada en una maquina diferente a la controladora
OpenDayLight. La máquina que lo ejecuta puede correr uno de los siguientes sistemas
operativos (todos de 64 bits):
RHEL 6/7
CentOS 6/7
Fedora (19/20)
Ubuntu (12.04/12.10/13.04/14.04)
Los pasos de instalación son los realizados en nuestro Ubuntu Server 14.04 (también sirven
para el 13.10). Para el resto de sistemas operativos, los pasos son equivalentes, pero los
comandos distintos.
Pasos previos a la instalación de VTN Coordinator
1. Instalación de paquetes necesarios:
“apt-get install pkg-config gcc make ant g++ maven git libboost-dev libcurl4-openssl-
dev \ libjson0-dev libssl-dev openjdk-7-jdk unixodbc-dev xmlstarlet”
2. Instalación de la base de datos para preparar la ejecución:
“apt-get install postgresql-9.3 postgresql-client-9.3 postgresql-client-common
postgresql-contrib-9.3 odbc-postgresql”
3. Instalación de las librerías gtest-devel y json-c:
apt-get install cmake libgtest-dev
cp -R /usr/src/gtest gtest-work
cd gtest-work
cmake CMakeLists.txt
make
sudo cp *.a /usr/lib
cd ..
rm -rf gtest-work
Después de cumplir los prerrequisitos, descargamos el código de la herramienta:
git clone https://git.opendaylight.org/gerrit/p/vtn.git
Para una instalación correcta, es necesario escribir los siguientes comandos donde se
construirá el código descargado y se instalará:
cd vtn
git checkout release/helium-sr3
cd coordinator
mvn -f dist/pom.xml install
tar -C/ -jxvf dist/target/distribution.vtn-coordinator-6.1.0.0-SNAPSHOT-bin.tar.bz2
Servicio VTN Coordinator Tenemos dos comandos importantes para el servicio:
- Iniciar: /usr/local/vtn/bin/vtn_start
- Parar: /usr/local/vtn/bin/vtn_stop
VTN Manager Este plug-in no tiene prerrequisitos, por lo tanto, no es necesario realizar instalaciones
adicionales. Además, tampoco hace falta descargar código como en el anterior.
Para instalar el plug-in es necesario instalar las siguientes características de la controladora
OpenDayLight a través de la consola Karaf (./bin/karaf en el directorio de la controladora):
“feature:install odl-vtn-manager-all odl-openflowplugin-all odl-adsal-compatibility-all”
Si encontramos algún error, podemos mirar el log de registro: data/log/karaf.log que nos dará
información sobre él.