OmniController. Infraestructura coordinada SDN y OpenFlow

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: [email protected]

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.



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.



Í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


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


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



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


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.


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


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.


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.


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.


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


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.


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.


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.


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.


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


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


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).


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ó)


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.


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


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


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')






info( '*** Add hosts\n')

h3 = net.addHost('h3', cls=Host, ip='10.0.0.3',

defaultRoute=None, mac='00:00:00:00:00:03')





info( '*** Add links\n')

net.addLink(s2, s1, bw=10, delay='0.2ms')



net.addLink(s3, h3, 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])



info( '*** Post configure switches and hosts\n')

CLI(net)

net.stop()

if __name__ == '__main__':

setLogLevel( 'info' )

myNetwork()


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.


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.


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.


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.


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.


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.


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.


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.


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.


La maqueta siguiente muestra la composición del escenario propuesto para que la aplicación

funcione correctamente:


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


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


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:


- 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.


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).



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.


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



Autor:






Logroño, La Rioja


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).

https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.2.3-Helium-SR3/distribution-karaf-0.2.3-Helium-SR3.tar.gz

https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.2.3-Helium-SR3/distribution-karaf-0.2.3-Helium-SR3.tar.gz

http://192.168.23.245:8181/dlux/index.html

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


Autor:






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

https://git.opendaylight.org/gerrit/p/openflowplugin.git

http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException



Autor:






Logroño, La Rioja


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.



Autor:






Logroño, La Rioja


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

https://git.opendaylight.org/gerrit/p/vtn.git

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.

Documents

OmniController. Infraestructura coordinada SDN y OpenFlow