Carlos arteche gonzalez

FACULTAD DE CIENCIAS
Facultad de Ciencias
Proyecto Fin de Carrera
DESPLIEGUE DE UNA MAQUETA DE
RED BASADA EN OPENFLOW
(Deployment of an OpenFlow-based
networking testbed)
Para acceder al Título de
INGENIERO EN INFORMÁTICA
Autor: Carlos Arteche González
Director: Ramón Agüero Calvo
Febrero - 2014

Índice
1. Introducción 6
1.1. Motivación y Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Estado del arte 8
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Redes Virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Software-Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . 14
2.4. Protocolo Openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. Despliegue de la maqueta Openflow 23
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4. Desarrollo de una interfaz web Openflow 41
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Conclusiones 50
6. Bibliograf´ıa y Referencias 51
A. Anexo 1 52
A.1. Tutorial OpenWrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B. Anexo 2 55
B.1. Código del módulo desarrollado . . . . . . . . . . . . . . . . . . . . . . . 55
B.2. Código del Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.3. Código de la aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . 69
1

Agradecimientos
En primer lugar, agradecer a Ramón Agüero Calvo por confiar en m´ı para realizar
este proyecto, el cuál ha sido interesante realizar, y por la ayuda ofrecida que ha sido de
gran utilidad.
A mis amigos y compañeros de clase, por haber pasado juntos los buenos y malos momen-
tos, dentro y fuera de la clase. A mis amigos de toda la vida por ayudarme y soportarme
a lo largo de los años.
También agradecer a mi familia por apoyarme durante todos estos años, especialmen-
te a mis padres y hermanos.
Muchas gracias a todos.
2

Índice de figuras
Figura 1, Red VLAN
Figura 2, Red VPN
Figura 3, Arquitectura SDN
Figura 4, Arquitectura SDN, con el protocolo OpenFlow
Figura 5, Red WAN de Google
Figura 6, Esquema de dispositivos
Figura 7, Modo Outband
Figura 8, Modo Inband
Figura 9, Switch OpenFlow
Figura 10, Muestra de configuración Switch
Figura 11, Captura OpenFlow
Figura 12, Estructura OpenFlow con Wireshark
Figura 13, Diagrama de eventos NOX
Figura 14, Captura inicial de la comunicación
Figura 15, Diagrama de conexión inicial
Figura 16, Captura de la configuración del router
Figura 17, Diagrama de configuración
Figura 18, Desconexión de un dispositivo desde Wireshark
Figura 19, Desconexión de un dispositivo, desde el punto de vista del controlador
Figura 20, MVC de una aplicación web
Figura 22, Diagrama del Controlador con el Conector
Figura 23, Diagrama de la web con el controlador
Figura 24, Modelo Cliente-Servidor
Figura 25, Login de la aplicación
Figura 26, Página principal de la aplicación
Figura 27, Información de los dispositivos
Figura 28, Página de creación de reglas
3

Resumen Ejecutivo
El concepto de Software Defined Networking (SDN) está ganando cada vez mayor
popularidad. El crecimiento de los data centers y la necesidad de disponer de tecnolog´ıas
de red que aseguren un comportamiento más adecuado por parte de las redes es ya una
realidad.
Los protocolos de encaminamiento y conmutación que se han venido usando hasta el
momento no parecen los más apropiados para dar respuesta a los retos que están apare-
ciendo. Uno de los representantes más importante en esta l´ınea es OpenFlow. Se trata
de una filosof´ıa nueva, en la que los planos de control y de usuario están claramente
separados. Tras una primera fase en la que se analizó el funcionamiento básico del proto-
colo y se llevó a cabo un despliegue con máquinas virtuales, en este trabajo se quiere ir
un paso más allá, y se pretende desplegar una maqueta basada en el protocolo OpenFlow.
Para ello se utilizarán equipos reales, más concretamente Routers WiFi del fabricante
TP-Link, que permiten modificar su comportamiento por defecto para integrar el proto-
colo OpenFlow. Una vez desplegada la maqueta se utilizará para llevar a cabo un conjunto
de pruebas de funcionamiento y medidas de rendimiento con la idea de disponer de un
testbed operacional para llevar a cabo experimentos y pruebas de SDN.
4

Executive Summary
Software Defined Networking (SDN) is goining popularity. The increasing growth of
data-centers, it, bring about need of a network technology leading to a better perfomances.
The routing and switching protocols traditionally used, do not seem the most appropria-
te to meet the challenges that are learning. One of the most important representatives
of this new approach, is OpenFlow. It a new philosophy where by the control and user
planes are clearly separated. After an initial phase, in which the basic operation of the
protocol was analyzed and assessed by virtual machines. This work goes one step further,
aiming to deploy a testbed based leverages on such protocol.
To fulfill this goal, we hace used real hardware, specifically Routers Wifi TP-Link, modif-
ying its default behavior to integrate the OpenFlow protocol. Once deployed, the testbed
will be used to carry out a number, of performance tests.
5

1. Introducción
1.1. Motivación y Objetivos
El principal objetivo de este proyecto es desplegar una maqueta OpenFlow, ya que se
está convirtiendo en una alternativa de gran interés para la Internet del Futuro. Empresas
como Google, lo está usando para la comunicación de sus data-center en todo el mundo.
En la actualidad hay una gran cantidad de protocolos funcionando, y todos causan pro-
blemas (de compatibilidad, por versiones de estos protocolos,etc.) que son muy dif´ıciles
de solucionar. Una posibilidad para solucionar estos problemas es actualizar todos los
dispositivos que componen Internet (routers, switches) pero esto ser´ıa muy costoso y las
compañ´ıas tendr´ıan que ponerse de acuerdo para definir una serie de requisitos. Open-
Flow simplifica toda la comunicación y control de los dispositivos, ya que con un único
protocolo común, nos facilita el control y gestión de la red.
Para poder entender lo anterior se pone en antecedentes para saber como se ha llega-
do a utilizar una tecnolog´ıa como esta. Para ello se explica que son las redes virtuales
(VLAN,VPN,...) y las redes Software Defined Network (SDN) que son redes definidas por
software.
Para acometer este despliegue en una red se tiene que cumplir una serie de requisitos,
que ser´ıan: unos dispositivos espec´ıficos como switch/es ó router/es, un software con el
cuál controlamos el protocolo en un servidor (un controlador) y el protocolo OpenFlow.
Además, y para una mejor administración de la red, se ha desarrolla en este proyecto,
un monitor web con el cuál se puede observar la topolog´ıa de la red y su funcionamiento.
También se utilizan otros programas para visualizar el flujo de paquetes que se intercam-
bian entre los dispositivos como es el Wireshark.
En resumen, los objetivos que queremos explicar en este proyecto ser´ıan los siguientes:
1. Antecedentes del protocolo OpenFlow, redes virtuales y redes SDN.
2. Explicación del protocolo OpenFlow.
3. Despliegue una red local con OpenFlow.
4. Creación de un monitor, a partir del controlador NOX.
1.2. Estructura de la memoria
Para afrontar adecuadamente los objetivos anteriores se ha estructurado la memoria
en los puntos que se enumeran a continuación:
1. En el Cap´ıtulo 3, se resumen los antecedentes, como son las Redes Virtuales y que
son las Redes Definidas por Software (SDN) y el protocolo OpenFlow.
2. En el Cap´ıtulo 4 se describe la implementación hardware que se ha desarrollado en
este proyecto.
6

3. En el Cap´ıtulo 5 se explica el desarrollo de software realizado.
4. El Cap´ıtulo 6, resume las principales conclusiones obtenidas durante la realizaci´on
de este proyecto.
7

2. Estado del arte
En este cap´ıtulo se pone en antecedentes, donde se resumen las Redes Virtuales y las
redes definidas por software (SDN).
2.1. Introducción
La información que se transmit´ıa por Internet inicialmente era m´ınima, por lo que
los problemas de colapso de la red no eran elevados. Si un paquete de datos no pod´ıa
atravesar algún punto de la red, se desviaba hasta que encontrase otro camino por el cuál
poder llegar a su destino. Sin embargo los flujos de datos que se transmiten hoy en d´ıa
por la red, como streaming de v´ıdeo, provocan problemas de colapso que hacen necesario
actualizar la estructura de la red.
Otro problema a tener en cuenta son los cortes puntales en la red. Lo ideal ser´ıa informar
de alguna manera a los nodos para que modifiquen la ruta del paquete. La manera que
actualmente se postula para acometer estas funcionalidades en las redes es a través de
las SDN, Software Defined Networking (redes definidas por software).
Son redes gestionadas remotamente, y de manera centralizada, por un software controla-
dor (NOX, POX, etc.); más adelante se enumeran algunos de estos desarrollos, en especial
NOX, que es con el que se ha trabajado en este proyecto.
Un controlador genera un mapa esquemático de la red, sobre el que puede controlar-
se el tráfico. Hoy en d´ıa, si se quiere modificar la gestión del tráfico, se tiene que hacer
de una manera menos automática, es decir, se tiene que intervenir directamente en el
dispositivo router o switch. Estos dispositivos tienen sus propias reglas, integradas en el
firmware, que establecen como reenviar el paquete. En cambio, con las redes SDN, se
permite la modificación de los flujos desde el controlador centralizado, lo que agiliza y
optimiza el tráfico. En este tipo de redes se pueden crear y modificar las reglas, lo que les
proporciona un gran potencial y versatilidad.
Para comunicar los diferentes dispositivos y con el controlador hay que hace uso del
mismo protocolo (conjunto de normas y reglas que permiten la comunicación entre dife-
rentes dispositivos). El que más éxito ha tenido por el momento es OpenFlow.
Este protocolo surgió de un proyecto que ten´ıa como objetivo experimentar fácilmente
con un parte de una red sin que afectara su operación. El potencial de OpenFlow llamo
la atención de empresas, que fundaron ONF (Open Networking Fundation) en 2011, con
el objetivo de extender el uso de este protocolo a las redes SDN.
2.2. Redes Virtuales
El gran problema de Internet es que su evolución es muy compleja de acometer. De-
bido a su gran popularidad, adoptar nuevas arquitecturas o introducir modificaciones en
las existentes, requieren de un consenso entre los distintos actores involucrados.
8

Esto implica que los cambios en la arquitectura estén restringidos a simples actuali-
zaciones y que desarrollar nuevos prototipos o procedimientos sea muy complicado. Una
posible solución es la virtualización, que se rige como elemento clave de la evolución de
las redes del futuro.
La virtualización consiste en la coexistencia de múltiples redes virtuales sobre el mis-
mo soporte f´ısico. Cada red virtual (VN) en un entorno de virtualización de redes (NVE),
se compone de una colección de redes y enlaces virtuales.
Dentro del marco de la virtualización de redes se pueden distinguir las alternativas que
se mencionan seguidamente,
1. Redes de área local virtuales (VLAN).
2. Redes virtuales privadas.
3. Redes activas.
4. Redes programables.
5. Redes overlay.
Redes VLANs
Figura 1: VLAN
Como se observa en la Figura 1, se ”generan”dos redes virtualizadas sobre una misma
red local. Las redes VLAN1 y VLAN2 no pueden interactuar entre s´ı, por lo que se puede
decir que son completamente independientes entre s´ı.
Las VLANs permiten definir una nueva red a un nivel superior al de la red f´ısica , ofre-
ciendo,(por ejemplo en la gestión de cambios y actualizaciones) las siguientes ventajas:
1. Mayor flexibilidad en la administración de la red, ya que la arquitectura puede
modificarse a través de los parámetros de los conmutadores.
9

2. Aumento de la seguridad, ya que la información tiene un nivel más de encapsulación.
Las VLANs están definidas por los estándares IEEE 802.1D, 802.1p, 802.1Q y 802.10.
Se han definido diversos tipos de VLANs, que se clasifican en cinco tipos diferentes:
1. VLAN de nivel 1 (por puerto): Se especifica que puertos pertenecen a la VLAN,
que es la más común.
2. VLAN de nivel 2: denominada VLAN basada en la dirección MAC, se define la
VLAN en función de su dirección MAC. Es mas flexible, permitiéndole la movilidad
del dispositivo. También se puede clasificar a nivel 2, por el tipo de protocolo de la
trama MAC, por ejemplo, VLAN1 IPv4, VLAN2 IPv6, etc.
3. VLAN de nivel 3: basada en la dirección de red que conecta subredes (subred vir-
tual). En este tipo de VLAN son los paquetes, y no los dispositivos, quienes perte-
necen a la VLAN.
4. VLAN a niveles superiores: Se crea una VLAN para cada aplicación, streaming de
v´ıdeo, correo electrónico, etc.
Redes Virtuales Privadas (VPN)
Para el intercambio de información entre nodos alejados geográficamente, y para evitar
que estas se vea comprometida, la solución mas extendida son las VPN. Son redes que
utilizan túneles, encapsulan los datos antes de ser enviados de manera cifrada. Únicamente
los equipos que pertenecen a una de área local de uno de los extremos de la VPN pueden
acceder a los datos.
Figura 2: VPN
En la Figura 2 se representan dos redes de área local conectadas a una red mayor
(como Internet); la tecnolog´ıa VPN permite conectar las dos redes sin utilizar una l´ınea
dedicada.
En una red privada virtual los datos están cifrados desde el momento que entran a la
VPN hasta que salen de ella y, por lo tanto, no pueden ser capturados por cualquiera que
no se encuentre en uno de los extremos de la VPN. La parte del cliente de la VPN es la
que cifra y descifra los datos del lado del usuario, mientras que el servidor es el elemento
que descifra los datos en el extremo correspondiente a la organización.
Un túnel es la técnica que consiste en encapsular un protocolo de red sobre otro creando
un túnel de información. El túnel queda definido por los puntos extremos y el protocolo
10

de comunicación empleado. Un ejemplo que utiliza esta tecnolog´ıa es SSH.
Los principales protocolos de túnel son:
PPTP (Protocolo de túnel punto a punto): es un protocolo de capa 2 desarrollado
por Microsoft, 3Com, Ascend, US Robotics y ECI Telematics.
L2TP: Protocolo de capa 2 basado en PPP, creado para corregir las deficiencias de
los protocolos PPTP y L2F.
IPSec (Internet Protocol security): Protocolo creado por IETF, cuya función es
asegurar las comunicaciones sobre el protocolo de Internet, autenticando o cifrando
cada paquete IP en un flujo de datos.
Con este mecanismo se proporciona una conexión segura a bajo coste, pero no se garantiza
una calidad de servicio comparable a la que ofrecen una l´ınea dedicada. Además, el cifrado
de los datos evita que usuarios externos a la VPN puedan visualizarlos.
Redes Activas
Este tipo de redes presentan una operación distinta, permitiendo la programación de
los nodos intermedios de la red, lo que supone un gran salto conceptual. Se propone
un nuevo paradigma de arquitectura de red, en la que los nodos operan como entornos
de ejecución abiertos en los que los usuarios pueden cargar y ejecutar código para el
procesamiento espec´ıfico de los flujos de datos.
Redes Programables
Las redes programables son aquellas que pueden ser programadas a partir de un con-
junto m´ınimo de APIs, pudiéndose componer un infinito espectro de servicios de alto
nivel. La programación de los servicios, de red se consigue mediante la integración de ca-
pacidad computacional, con mucho mas potencial que los routers y switches tradicionales.
Por ejemplo, disponiendo de un router, una API y un kit de desarrollo (SDK) se pueden
crear aplicaciones y permitir interactuar a éstas todas las capas de red.
Redes Overlay
Este tipo de redes integran diferentes recursos, a través de una aplicación que mantiene
simultáneamente la conectividad, proporcionando todos los demás servicios relacionados
con el mantenimiento de la red. Se denomina overlay por ”situarse por encima”de otras
redes y, especialmente, por presentar una arquitectura independiente de las mismas. La
forma más fácil de conseguir esta funcionalidad es añadiendo capas sobre los protocolos
de las redes subyacentes.
El ejemplo más claro, y simple, de una red Overlay la encontramos en numerosos ho-
gares. Se dispone de una red Ethernet, a la que se conectan varios equipos,lo que es
suficiente para enlazar la comunicación entre ellos, pero no para conectarlos con otras
redes. Para ello es necesario añadir una capa de red y un router, con lo que se crea una
11

red superpuesta.
En resumen, (a nivel de enlace) los objetivos de la virtualización de red son los siguientes:
1. Flexibilidad y heterogeneidad.
2. Capacidad de gestión.
3. Aislamento.
4. Programabilidad.
5. Facilidad en el desarrollo e investigación.
6. Soporte a sistemas tradicionales.
El objetivo de explicar lo anteriormente, es para que se entienda una de las bases del pro-
tocolo OpenFlow, la cuál es una tecnolog´ıa de virtualización de red que nos proporciona
flexibilidad y control para configurar la red. Con lo que simplifica la complejidad de los
dispositivos y automatiza las tareas de gestión. Todo esto se explicará mas adelante.
2.3. Software-Defined Networking (SDN)
Hasta ahora han predominado las redes modelo cliente-servidor, basadas en una ar-
quitectura estática. Las nuevas tendencias, como el uso masivo de dispositivos móviles,
la virtualización de servidores, los servicios en la nube, etc. por tanto, hacen que esta
arquitectura se vuelva inadecuada.
Las redes SDN tienen, como objetivo global abrir el control de los flujos de red hacia
un software, independiente del hardware espec´ıfico en cada caso.
SDN separa el plano de control del plano de datos, lo que no se da en las redes de
datos tradicionales. Lo que se pretende es disociar la infraestructura de la red de las apli-
caciones y servicios presentes en ella, que ven a la red como entidad virtual o lógica.
En lo referente al control sobre la red, esto se da básicamente a través de la programación
de reglas que definen patrones y comportamientos de tráfico mientras este transita por
la red. Estas reglas son programadas en un dispositivo denominado servidor controlador
SDN (NOX, POS, Beacon, etc). La gestión de la red se encuentra altamente centralizada
sobre este dispositivo que maneja toda la inteligencia de la red.
Esta independencia da un gran potencial, presentado grandes beneficios, tal y como des-
taca Google tras la implementación de SDN en su red interna.
Visión unificada de la estructura de red: Lo que garantiza facilidad de gestión y
configuración.
Mejor aprovechamiento de la red: La gestión extremo a extremo de la red nos
permite incrementar la utilización de los enlaces.
12

Figura 3: Arquitectura SDN
Mejor mantenimiento: Los fallos se gestionan mas rápido.
Entorno de pruebas de alta fidelidad: La emulación de todas las redes incluyendo
la dorsal, facilita los procesos de verificación permitiendo distintos escenarios.
Elasticidad en el cómputo: Los dispositivos ya no son un factor limitador, en cuanto
a su capacidad y gestión, ya que todo el control reside en los servidores y controla-
dores.
Actualizaciones transparentes: La separación de software y hardware permite llevar
a cabo procesos de actualización sin que se produzcan periodos sin servicio.
Personalizar la red y sus servicios.
Aumento del rendimiento.
Arquitectura SDN
La arquitectura SDN está basada en un servidor controlador, el cual inspecciona los
patrones del flujo de datos, de acuerdo a las reglas definidas en él, y los dispositivos de
interconectividad, los cuales se encargan de recibir órdenes del controlador y aplicarlas.
En la Figura 3, se observa una arquitectura sencilla de una red SDN, que se compone
de un controlador, unos dispositivos y un protocolo para comunicarse con los dispositivos.
El concepto SDN es relativamente nuevo, y han surgido múltiples enfoques y soluciones.
Actualmente las que más éxito han tenido son: OpenFlow y Path Computation Element
(PCE).
13

Las ventajas de un arquitectura SDN se detallan a continuación:
Administración centralizada de la red, con un solo dispositivo (controlador).
Se dispone de una red con soporte de diferentes marcas de equipos de conectividad,
con solo hacer pequeñas modificaciones al firmware.
Automatización de la gestión de la red a través de Interfaces de Programación de
Aplicaciones (API) que son las encargadas de la abstracción de la red subyacente.
La seguridad de la red se incrementa debido a una mejora en la confiabilidad pro-
vocada por el manejo centralizado de dispositivos.
Se obtiene un mejor servicio, ya que las redes se adaptan fácilmente a los cambios.
El controlador facilita la programación por parte del administrador.
Controlador SDN
El controlador es el núcleo central de la arquitectura SDN, ya que es el que tiene toda
la lógica de la red. En el controlador se definen las reglas para administrar el flujo de
datos en la red. Esto permite una configuración mas rápida que en las redes tradicionales,
donde se espera a que el fabricante lo haga, al igual que la implementación de nuevas
aplicaciones y servicios.
En este proyecto se centra en el estudio de OpenFlow, que se explica con detalle a conti-
nuación.
Resumen SDN
En resumen, el objetivo de las SDN es, utilizando un software controlador, permitiendo
gestionar todos los dispositivos (router,switch, etc) de la red, en concreto las reglas que
emplean para procesar los diferentes flujos de información.
2.4. Protocolo Openflow
El protocolo OpenFlow surgió en la universidad de Standford, propuesto inicialmente
por Nick McKeown, que busca abrir Internet a los investigadores, permitiéndoles ejecutar
protocolos experimentales. OpenFlow es el primer estándar que se ha desarrollado para
una SDN. Este protocolo permite la manipulación del plano de datos, al especificar las
primitivas básicas usadas por las aplicaciones.
Se usa entre los dispositivos de red y el controlador SDN, para manejar los flujos que
se transmiten en la red indicándole una acción adecuada, mediante las reglas predefinidas.
OpenFlow permite utilizar aplicaciones remotas para acceder a las tablas de flujo y con-
trolar as´ı el tráfico desde un terminal externo. Cuando un paquete de datos llega a un
14

switch o router, el firmware del dispositivo comprueba el destino del paquete, y lo reenv´ıa
de acuerdo a las reglas predefinidas que en una operación tradicional no se pueden cam-
biar. En una red con OpenFlow, sin embargo todas estas reglas pueden modificarse, quitar
y añadir otras, según los objetivos concretos que se buscan. Por ejemplo, para reducir co-
rrespondiente al tráfico de correo electrónico para dar prioridad al streaming de v´ıdeo, etc.
En resumen. el protocolo OpenFlow indica al tráfico como fluir por la red; Las reglas
son definidas para cada flujo, con lo que se mantiene un control más exhaustivo de la red.
En la Figura 4 se observa una jerarqu´ıa de componentes de una red SDN que utiliza
el protocolo OpenFlow. En el primer nivel se localiza el hardware, los routers conectados
al servidor. En un segundo lugar se tiene el software controlador, que se ha explicado an-
teriormente. La tercera jerarqu´ıa abarca las aplicaciones que se ejecutan sobre OpenFlow.
Y, por último, las herramientas de monitorización y control de errores de la red.
Arquitectura OpenFlow
Figura 4: Arquitectura SDN con el protocolo OpenFlow
En la Figura 4 se presenta una arquitectura SDN, ejecutando el protocolo OpenFlow.
En ella se hallan componentes como el software controlador, routers OpenFlow y el propio
protocolo OpenFlow, que se describen seguidamente.
Controlador. Hay varias alternativas, implementaciones en diferentes lenguajes, pe-
ro en este proyecto se ha trabajado con uno concreto, NOX, cuya operación se
describirá con detalle en el siguiente cap´ıtulo.
Router o Switch que deben ser compatibles con el protocolo OpenFlow integrado.
15

El protocolo OpenFlow en concreto, que proporciona el medio por el cual el con-
trolador se comunica con los dispositivos de la red.
FlowVisor, software que actúa como Proxy cuando se tienen varios controladores
OpenFlow.
Conmutador OpenFlow
El router o switch es un dispositivo de conectividad, que además se conecta con el ser-
vidor controlador con el fin de recibir las reglas que definirán patrones de flujo mediante
OpenFlow.
OpenFlow permite gestionar y controlar los flujos de datos mediante software. Para ello,
se incorpora en todos los componentes de red (routers, switches y puntos de acceso) un
módulo de firmware de OpenFlow, permitiendo llevar a cabo modificaciones más o menos
complejas y avanzadas. As´ı, se tiene acceso a las tablas de flujo y a las reglas que emplean
routers y switches para direccionar el tráfico en la red. Sin embargo, no especifica las
instrucciones de asignación de los diferentes dispositivos, que son los que diferencian el
hardware de cada fabricante.
Un conmutador OpenFlow consiste de 3 partes diferenciadas:
Tabla de flujos (flow-table), con una acción asociada a cada entrada (flow-entry),
en la que se indica al nodo la manera de gestionar el flujo correspondiente.
Canal de comunicaciones. Este canal conecta el controlador con el switch, mediante
el uso del protocolo OpenFlow.
Protocolo OpenFlow. Habilita la comunicación entre el controlador y el switch.
As´ı se evita programar el switch directamente. El controlador se encarga de enviar
las reglas, y los nodos las guardan en sus flow-table.
Los flujos están limitados por la flow-table de cada dispositivo. Cada flujo de entrada
tiene una acción asociada. Las tres más básicas, soportado por todos los dispositivos, son
las que se enumeran a continuación,
Reenv´ıo de los paquetes de un flujo a un determinado puerto.
Encapsular y reenviar los paquetes de un flujo hacia un controlador.
Descartar los paquetes de un flujo.
La definición de flujo se asocia a una serie de paquetes con encapsulación TCP, que
se env´ıan en una comunicación.
Los conmutadores OpenFlow pueden ser clasificados en dos categor´ıas, según la imple-
mentación del protocolo,
Conmutador OpenFlow dedicado: El protocolo viene incorporado en el dispositivo.
Este dispositivo no tiene inteligencia por s´ı mismo, ya que env´ıa el tráfico como le
indica el controlador. No da soporte a las capas 2 y 3.
16

Conmutador OpenFlow habilitado: OpenFlow no viene inclu´ıdo, pero se puede
añadir mediante las actualizaciones del firmware. Se añade una tabla de flujos,
el canal seguro y el protocolo OpenFlow.
En este proyecto, los conmutadores que se ha empleado son de tipo habilitado.
En resumen se puede decir que los dos objetivos principales de OpenFlow son permi-
tir a los usuarios definir los flujos, y establecer los caminos que deben tomar a través de
la red. Todo esto sin interrumpir o interferir en el tráfico habitual de la red.
OpenFlow tiene una gran flexibilidad, permitiendo varios escenarios en su diseño:
Control Centralizado o Distribuido. En el control centralizado se dispone de un único
controlador, y todos los switchs se conectan a él. En el distribuido hay controladores
entre los que se reparte la gestión de los nodos de red.
Enrutamiento de flujo o Agregación. Con el enrutamiento se trata al flujo indivi-
dualmente y con el agregado se agrupan un conjunto de flujos que se gestionan de
manera común.
Reactivo o Proactivo. Con el modo reactivo el primer paquete del flujo genera la
“creación”del mismo en el controlador, mientras que en el esquema proactivo el
controlador se configura previamente la tabla de flujo.
OpenFlow se basa en las tablas de flujos (flow-tables), t´ıpicamente construidas en TCAMs
(Ternary content-addressable memory), integradas en switches y routers, siendo diferentes
para cada fabricante. Sin embargo se han identificado un conjunto de funciones comunes
para todos ellos. OpenFlow hace uso de dichas funciones.
La tabla de flujos (flow-table) OpenFlow incluye los siguientes campos:
Encabezado del paquete, que define el flujo.
La acción, procesamiento del paquete.
Información estad´ıstica.
El camino de datos (datapath) que utiliza un switch OpenFlow consiste en una flow-
table y una acción a aplicar a cada entrada de la misma. Para garantizar un alto ren-
dimiento, sin incurrir en un coste elevado, el datapath debe presentar cierto grado de
flexibilidad. Esto supone renunciar a la posibilidad de especificar una gestión arbitraria
de cada paquete, buscando un conjunto de acciones más limitado, pero útil.
Además, permite dividir el tráfico en diferentes grupos. Cada usuario, o grupo de usua-
rios puede controlar su propio flujo en la red, seleccionando las rutas que los paquetes
deben seguir, as´ı como las reglas para su gestión. En la misma red, el tráfico habitual
(producción) es aislado y procesado tal y como se gestiona en un dispositivo tradicional.
17

Mensajes OpenFlow
OpenFlow cuenta con una gran cantidad de mensajes que le permiten transmitir
acciones e información desde el controlador hacia los dispositivos. Se clasifican en:
Mensajes del controlador al conmutador; se generan en el controlador, y el con-
mutador necesariamente responde al mensaje. En esta categor´ıa se encuentran los
siguientes mensajes:
• Features: se env´ıa cuando el controlador requiere obtener las caracter´ısticas
del conmutador, que le responde con sus caracter´ısticas. Se usa normalmente
en el establecimiento de una conexión OpenFlow.
• Configuration: mensajes de consulta de los parámetros de configuración del
conmutador.
• Modify-State: se env´ıan desde el controlador para la gestión de estados en el
conmutador, como por ejemplo añadir o quitar flujos o cambiar el estado de
un determinado puerto.
• Read-State: El controlador lo usa para adquerir las caracter´ısticas del conmu-
tador.
• Packet-Out: El controlador los usa para enviar paquetes por un determinado
puerto del conmutador y para redireccionar paquetes Packet-In. Encapsula el
paquete a ser redireccionado y las acciones que se aplicarán al mismo.
• Barriel: El controlador lo usa para asegurarse que las dependencias de un men-
saje se han cumplido o para recibir notificaciones por operaciones finalizadas.
Mensajes as´ıncronos, estos mensajes se env´ıan desde los conmutadores al contro-
lador, cuando un paquete llega, cambio de estado tras un error. En este tipo de
paquetes están:
• Packet In: Paquete enviado desde el conmutador hacia el controlador cuando
no tiene una entrada en su tabla de flujos que concuerde con el paquete entran-
te. El controlador procesa el paquete y responde con un mensaje Packet-Out.
• Flow-Removed: Se env´ıa cuando el tiempo de inactividad de un flujo suspira.
Puede ser enviado tanto por el controlador como por el conmutador.
• Port-Status: Se env´ıa del conmutador al controlador cuando la configuración
de un puerto cambia.
• Error: El conmutador notifica al controlador si existen problemas con estos
mensajes.
Mensajes s´ıncronos, estos mensajes se env´ıan desde cualquier lugar, controlador
o dispositivo sin solicitud previa. En esta clasificación se encuentra los siguientes
mensajes:
• Hello: Estos mensajes se intercambian al momento del establecimiento de la
conexión entre los conmutadores y el controlador.
18

• Echo: Se usan para medir la latencia o el ancho de banda o para verificar que
un dispositivo esté activo. Por cada petición que llegue al destino, se creará una
respuesta que será enviada al origen. Puede ser enviado por el conmutador o
el controlador.
• Experimenter: Permite dar funcionalidades adicionales a un conmutador Open-
Flow, habiendose planeado para futuras versiones del protocolo.
En el Anexo 3 se enumeran todos los mensajes OpenFlow con sus posibles respuestas.
Open Networking Foundation (ONF)
Actualmente la Open Networking Foundation (ONF), está adquiriendo un gran pro-
tagonismo como alternativa para garantizar la seguridad, fiabilidad y ahorro de costes en
la creación de redes a nivel de global. Actualmente consta de más de 50 empresas, que
trabajan en la creación de normas, productos y aplicaciones que cambiarán la filosof´ıa de
las redes actuales.
El objetivo de esta fundación es crear las normas más revelantes del SDN, potencian-
do su papel en la Internet del Futuro. Esta organización, está formada por empresas
como Google, Facebook, Microsoft, etc, no tiene ánimo de lucro, y su objetivo es cambiar
la filosof´ıa actual en la creación de redes, llevando al mercado estándares y soluciones de
manera rápida.
Hasta hace poco las SDN no era mas que proyecto interesante, pero con poco desa-
rrollo real; sin embargo cuando Google anunció que hab´ıa implementado OpenFlow en
toda su red interna, la situación cambió radicalmente.
Figura 5: Red WAN de Google
En la Figura 5 se muestra la red WAN de Google, que está organizada en dos redes
dorsales (backbones):
Una red destinada a los usuarios (I-scale).
La red interna, que transporta el tráfico entre sus data-centers (G-Scale).
En la red G-Scale ha implementado la solución OpenFlow, con el objetivo de gestio-
nar el tráfico entre sus data-centers, que se conectan entre s´ı. Se han desplegado varios
controladores OpenFlow para gestionar los nodos de conmutación.
19

3. Despliegue de la maqueta Openflow
Cap´ıtulo que explica el despliegue de la maqueta OpenFlow, y los resultados obtenidos
en su desarrollo.
3.1. Introducción
Para poder entender como funciona OpenFlow se ha implementado una red local,
compuesta por dos router, un servidor donde está el controlador NOX y equipos para
poder realizar las pruebas. OpenFlow no funciona en todos los dispositivos de red (swit-
ches, puntos de acceso, routers, etc). Para analizar la operación de este protocolo se ha
utilizado un hardware espec´ıfico, compatible con la versión de OpenFlow.
A no disponer de un switch que tenga incorporado OpenFlow, se han utilizado unos
routers WiFi (TP-Link TL-WR1043ND versión 1.11) y se ha cambiado el firmware que
traen incorporado por OpenWrt, ya que es compatible con OpenFlow.
Figura 6: Esquema de dispositivos
En la Figura 6 se muestra un esquema de la red implementada; se observa que el
servidor NOX está conectado de una forma centralizada, a los dos routers, mientras que
los equipos se concentran con los routers.
Se dispone de muchos controladores para poder crear y controlar redes SDN basados
en OpenFlow, pero se ha utilizado el NOX ya que fue el primer controlador utilizado
para OpenFlow.
Para poder analizar el tráfico de la red se ha utilizado la herramienta Wireshark, en
la que se ha tenido que instalar un plugin para poder visualizar el tráfico de los paquetes
OpenFlow.
Adicionalmente, se ha implementado un monitor web, el cuál nos muestra información
de la red OpenFlow creada, los dispositivos que hay, reglas utilizadas, etc.
En este cap´ıtulo se va a explicar que hardware y software que se ha utilizado y que
han llevado a su elección.
20

3.2. Hardware
En esta sección se va a explicar el hardware necesario para para desplegar la maqueta,
empezando por los routers que se han utilizado. Como se ha comentado anteriormente se
necesitan unos routers espec´ıficos que tienen que ser compatibles con la versión adecuada
de OpenWrt, y este es compatible con OpenFlow.
Se han elegido el router TP-Link TL-WR1043ND versión 1.11, con un procesador potente
(procesador Atheros AR9132@400MHz) y compatible con la versión Attitude Adjustment
12.09 de OpenWrt. Si por algún casual se actualiza el firmware del router con una versión
de OpenWrt no compatible con el router, este puede que deje de funcionar y se tenga que
reiniciar a través del puerto serie.
OpenWrt es una distribución GNU/Linux cuya finalidad principal son los dispositivos
embebidos, se caracteriza por ser de código abierto, bajo licencia GPL, que de fácil y
libre acceso, por lo que todo el mundo puede modificar el código para mejorar o cambiar
su funcionalidad, como el usuario desee. Incluye caracter´ısticas que no incorporan otros
fabricantes en sus routers como VPN, QoS, servidor de archivos, nodos P2P, etc.
OpenWrt es un firmware estático, un sistema de ficheros que se gestiona por paque-
tes. Esto permite al usuario personalizar el dispositivo, incorporando cualquier paquete
para adaptarse a diversas aplicaciones. El objetivo de OpenWrt es continuar expandiendo
su funcionalidad, y asegurar que sea el principal marco de desarrollo de soluciones inno-
vadoras.
Anteriormente se ha dicho que es un sistema por paquetes, para el cuál se requiere el
firmware OpenWrt y el módulo correspondiente de OpenFlow, con la versión 1.3 para in-
cluirlo dentro del firmware. Una vez configurada la imagen de OpenWrt se compila para
as´ı actualizar el firmware del router, siendo necesario conectar al router y, desde el panel
de administración, seleccionar la imagen adecuada.
Una vez actualizado le firmware del router se tiene que configurar el protocolo OpenFlow.
Primero es necesario conectarse al router través del protocolo ssh, para modificar el fiche-
ro de configuración /etc/configuration/openflow. En este fichero se tiene los parámetros
de configuración del protocolo OpenFlow:
dp: nombre del datapath.
ofports: puertos del switch OpenFlow.
ofctl: dirección ip donde se encuentra el controlador.
mode: tipo de red que desea: inband1
o outband2
. Son caracter´ısticas de los proto-
colos de red con los que se regula el control de datos.
Modo inband: Los datos de control se env´ıan compartiendo la misma conexión que los de
usuario. Modo outband: Los datos de control se env´ıan independientemente.
1
inband: Los datos de control se env´ıan compartiendo la misma conexión que los de usuario.
2
outband: Los datos de control se env´ıan independientemente.
21

Un ejemplo de configuración outbound ser´ıa la que se muestra en la Figura 7:
Figura 7: Modo Outband
La Figura 8 ejemplo de una configuración en modo inband:
Figura 8: Modo Inband
En el caso de la configuración inband se añaden los siguientes parámetros:
ipaddr : Dirección de configuración del switch OpenFlow.
netmask : máscara de red del switch OpenFlow.
gateway : gateway del switch OpenFlow.
Para aplicar los cambios se tiene que reiniciar el servicio OpenFlow:
$/etc/init.d/openflow restart
En esta red se ha configurado en modo Outband, con la configuración que se refleja
la Figura 9.
Figura 9: Switch OpenFlow
Como se puede ver, as´ı como indica la ip del servidor donde se localiza el controlador
y el puerto donde se escucha, los puertos del switch disponibles para el protocolo Open-
Flow. El dpid es el número que identifica el router en el controlador SDN. Se configura
también el datapath, y el modo de operación.
El router contiene cinco puertos y varios mas en la red wifi. En este proyecto no se
22

necesita la red wifi por lo que no hay que configurarla. Pero s´ı se tiene que configurar la
red Ethernet tal y como se muestra en la Figura 10:
Figura 10: Muestra de configuración Switch
La parte de la derecha de la Figura 9 muestra la configuración de los puertos nece-
sarios para el funcionamiento con OpenFlow. En este caso se han añadido los cuatros
puertos disponibles en el router.
Una vez finalizada la configuración del router ya está listo para su funcionamiento.
Además del router se necesita un switch, que no requiere ninguna configuración espe-
cial, cuyo objetivo es conectar los routers con el equipo que contiene el controlador el
servidor (controlador NOX).
En el Anexo 1 se detalla el procedimiento para crear la imagen OpenWrt, para actualizar
y configurar el router.
3.3. Software
En este apartado se va a explicar el software que se ha sido necesario para la realiza-
ción de este proyecto. En concreto, el controlador OpenFlow, NOX y el Wireshark.
El núcleo de la red OpenFlow es su controlador, descrito anteriormente. Los controla-
dores funcionan como un sistema operativo de red, tienen una visión general de la misma
y las aplicaciones que se ejecutan en el controlador son las que determinan el comporta-
miento de los flujos por la red.
Existen numerosos controladores, en diferente lenguajes de programación, como:
23

NOX, implementado en C++ y Python. Este es un controlador que soporta Open-
Flow, y fue el primero desarrollo.
MUL, implementado en C.
POX, implementado en Python y que soporta OpenFlow.
JAXON, controlador en Java.
Trema, Desarrollado en C / Ruby.
Beacon, Desarrollado en Java.
NOX
El proyecto se centra en el controlador NOX, desarrollado por Nicira networks y do-
nado a la comunidad cient´ıfica y de desarrolladores. La versión de OpenFlow que se
implementa en este proyecto es la 1.3, por lo que, es necesario el controlador NOX que
permite trabajar con esta versión. Este controlador solo es compatible con algunos siste-
mas Linux como Ubuntu y Debian.
Las principales caracter´ısticas de NOX son:
Incluye una API de C++.
Entrada y salida rápida (sincróna y as´ıncrona), es decir, controla la entrada y salida
de un gran flujo de datos en cualquier instante de tiempo.
Actualmente se encuentran disponibles dos versiones del controlador NOX:
NOX Classic: es una versión antigua que ofrece soporte para Python y C++; sin
embargo, la versión fue descontinuada y ya no existe actualmente desarrollo en esta
l´ınea. No se recomienda implementar esta versión; sin embargo, cuenta con un rango
de módulos más amplio.
NOX: es la nueva versión de este software. Ofrece soporte exclusivamente para C++.
Sin embargo, ofrece un rango de aplicaciones reducido, en comparación a la versión
clásica. Su funcionamiento es más rápido y cuenta con un código más depurado.
Esta versión, actualmente, se encuentra en continuo desarrollo.
Los objetivos de este software controlador son:
Proporcionar una plataforma que permita a los desarrolladores realizar innovaciones
en la gestión y control de la red.
Tener un manejo centralizado de dispositivos de conectividad, como por ejemplo
conmutadores, un control de admisión a nivel de usuario y un motor de pol´ıticas de
seguridad para la red.
24

NOX ofrece métodos de bajo nivel para interactuar con la red en su forma más básica.
Las funciones de alto nivel y los eventos son creados o proporcionados por aplicaciones
de red que se denominan componentes, que son encapsulados, y ofrecen un cierto tipo de
funcionalidad. Por ejemplo, las funciones de enrutamiento se encuentran encapsuladas en
un componente. Si se requiere agregar enrutamiento a una red, se debe declarar el encap-
sulado de enrutamiento como dependencia, para poder hacer uso de esta caracter´ıstica.
Las aplicaciones se dividen en varios grupos, dependiendo de sus funcionalidades. Las
más importantes son las denominadas de core o núcleo. Los componentes de núcleo se
encuentran bajo el directorio src/nox/coreapps. A continuación se presentan ejemplos de
los mismos:
Messenger: incluye las funcionalidades de sockets TCP (Transmission Control Pro-
tocol) o SSL (Secure Socket Layer) para la comunicación del controlador con otros
dispositivos de la red.
SNMP (Simple Network Management Protocol): permite el manejo de traps SNMP
usando un script escrito en el lenguaje Python. El manejo de traps se realiza me-
diante Net-snmp.
Otro tipo de componentes son las aplicaciones de red, que como su nombre in-
dica, brindan funcionalidades de red. Los componentes de red están en el directorio
src/nox/netapps. A continuación se presentan ejemplos de los mismos:
Discovery: Permite descubrir y monitorizar a los diversos enlaces que existan entre
conmutadores dentro de un dominio.
Topology: Permite mantener un registro de los enlaces activos de la red.
Monitoring: Este componente consulta periódicamente a los conmutadores de la red
para obtener estad´ısticas, que posteriormente son presentadas. As´ı se obtiene una
visión del funcionamiento de la red y se pueden detectar posibles problemas.
POX
POX, es un controlador similar al NOX, pero se diferencian en que POX usa el len-
guaje Python para programar las reglas, y NOX utiliza tanto Python como C++. Fue
creado con el fin de permitir un desarrollo rápido y dinámico de reglas de flujo.
Beacon
Controlador que permite programar las reglas de flujo, escrito en Java, lo que asegura
un carácter multiplataforma y modular.
25

Floodlight
Controlador escrito en Java y que necesita de una máquina virtual, para poder ejecu-
tarse.
Instalar controlador NOX
Una vez explicado el controlador NOX se procede a su instalación en el servidor, para
ello, el siguiente paso es bajarse el controlador NOX con la version 1.3 de OpenFlow.
Además de soportar la última versión de OpenFlow, también soporta múltiples conexio-
nes, aunque no permite trabajar con aplicaciones implementadas en Python como ocurre
en versiones anteriores.
Para instalar NOX en el sistema, es necesario una serie de requisitos. Se trata de unos
paquetes que se utilizan para poder compilar el controlador, y desarrollar las aplicaciones
correspondientes. Una vez finalizada la instalación de los paquetes necesarios, se necesitan
otros requisitos fundamentales, como son las dependencias del controlador NOX. Una vez
finalizado ya se tiene el equipo preparado para instalar el controlador.
$ sudo update
$ sudo apt-get install build-essential binutils flex bison autoconf
gettext texinfo sharutils subversion libncurses5-dev ncurses-term
zlib1g-dev gawk
$ sudo apt-get install nox-dependencies
El último paso para acabar de instalar NOX es compilar los ficheros fuente del contro-
lador. Si se ha creado algún módulo o se ha producido alguna modificación en el módulo
o en el núcleo del controlador se tiene que volver a compilar el controlador.
$ ./boot.sh
$ mkdir build
$ cd build/
$ ../configure
$ make
Antes de ejecutar el controlador se tienen que tener en cuenta el puerto donde se
ejecutará, que es por defecto el 6633. Este puerto se configura en el router, descrito an-
teriormente.
Para ejecutar el controlador se ejecuta la siguiente instrucción:
$ ./nox_core -i ptcp:6633 "aplicacion" -v
Con la opción -i indica el puerto donde escucha el controlador NOX (6633).
Con la opción -v indica que se ejecuta de forma ”debug”, que indica paso a paso
como se ejecuta el controlador.
El nombre de la aplicación indica que aplicación se va ejecutar, ya sea un ejemplo
del controlador o una aplicación desarrollada por el usuario.
26

Una vez ejecutado el controlador, este se queda escuchando el puerto, esperando a que
se conecten los dispositivos.
Una vez estén conectados los dispositivos al controlador, este env´ıa las reglas a los routers
destinatarios. Para saber si un dispositivo sigue activo o esta disponible el controlador
env´ıa una señal al dispositivo cada cierto tiempo (HELLO); si el dispositivo devuelve una
señal quiere decir que está disponible.
Figura 11: Captura OpenFlow
En la Figura 11 se muestra una captura del protocolo OpenFlow, obtenida en el
momento en el que se conectan los routers y el controlador. Se muestran los mensajes
para definir los parámetros de configuración de la comunicación. Los puntos que aparecen
a continuación son los más importantes de esta captura.
1. Indica el protocolo y la versión correspondiente.
2. La dirección IP del dispositivo origen, que en este caso se corresponde con el con-
trolador.
3. La IP destino, que se corresponde con el router 1.
4. La IP destino, que se corresponde con el router 2.
5. Tipo de mensaje OpenFlow, el OFPT HELLO se emplea para mantenener viva la
comunicación.
6. Mensaje para solicitar los parámetros de la configuración.
7. Modifica la configuración del switch.
8. Respuesta del router al mensaje 6.
9. Indica la configuración del puerto.
10. Mismo tipo de mensaje que el 7, pero interactuando con el router 2 en este caso.
27

Para llevar a cabo la captura se ha utilizado, como se adelantará previamente, Wireshark,
un analizador de protocolos open-source, utilizado para realizar análisis y solucionar pro-
blemas en redes. Permite ver todo el tráfico que pasa a través de una red. Incluye un
completo sistema para filtrar las tramas capturads en función de múltiples parámetros y
la habilidad de mostrar el flujo reconstruido de una sesión de TCP. Es compatible con la
mayor´ıa de los sistemas operativos, Linux, Mac OS X y Windows.
Wireshark interpreta la estructura de los protocolos, y muestra amigablemente los campos
de cada una de las cabeceras y capas que componen el paquete.
Figura 12: Estructura OpenFlow con Wireshark
En la Figura 12 se observa la estructura de un paquete OpenFlow. Se explican los
principales, que son los indicados en la Figura 12:
1. Indica el protocolo que se analiza.
2. La cabecera del protocolo.
3. Tipo de mensaje transmitido.
4. Identificador del datapath.
5. Configuración de los parámetros de configuración del switch.
En un principio Wireshark no soporta el protocolo OpenFlow, por lo que es necesario
instalar ofdissector para la versión 1.3 de OpenFlow.
Para instalar Wireshark en Ubuntu se siguen los siguientes pasos:
28

$ sudo apt-get install wireshark-dev
$ sudo apt-get install scons
$ export WIRESHARK=/usr/include/wireshark
$ cd src //dentro de la carpeta del ofdissector
$ scons install
Para capturar paquetes directamente de la interfaz se necesitan permisos especiales,
por lo que se tiene que ejecutar en modo administrador.
Wireshark se localiza en la parte del servidor, para capturar el tráfico que transmiten
los dispositivos al controlador.
Módulo desarrollado
Teniendo en cuenta que la versión NOX seleccionada está escrita en C++, todos los
“programas”desarrollados para este controlador, deberán emplear el mismo lenguaje de
programación.
El desarrollo de software para el controlador NOX, puede llevarse a cabo de dos for-
mas distintas, la primera, creando un complemento partiendo desde cero, y la segunda, a
partir de uno de los ejemplos dados, se modifica el código generando la aplicación desea-
da. NOX dispone de una API 3
para ayudar al programador a desarrollar las aplicaciones
correspondientes.
Cada aplicación desarrollada en NOX debe tener una clase que debe usar el nombre
de la aplicación. En estas clases es donde se controlá los mensajes OpenFlow; además se
tienen que implementar siempre dos métodos: configure e install. El primero es útil para
tener los parámetros de la configuración y su contexto, mientras que el segundo se usa
para registrar mensajes. Además, cada clase hereda de Component e incluiye la macro
REGISTER COMPONENT, como se ve a continuación.
class MyApp : public Component{
public: MyApp(const Context* c, const json_object*)
: Component(c) { }
void configure (const Configuration*);
void install ();
/*handle para manejar los mensajes*/
3
http://www.noxrepo.org/ /nox-classic-doxygen/index.html
29

Disposition handle(const Event&);
};
REGISTER_COMPONENT (container::Simple_component_factory<MyApp>, MyApp);
El método install se usa para instalar los manejadores de los mensajes. El ejemplo
siguiente muestra el registro a un evento Packet in, que será lanzado para cada paquete
que llega al controlador,
void install()
{
register_handler(Ofp_msg_event::get_name(OFPT_PACKET_IN),
boost::bind(&MyApp::handler, this, _1);
}
El manejador handler se tiene que implementar dentro de la clase, y siempre retorna
un Disposition, que puede ser CONTINUE, y proceder al siguiente listener, o STOP, que
finaliza el evento procesado.
Disposition handler (const Event& e)
{
return CONTINUE;
}
Para crear y mandar mensajes al controlador OpenFlow, se emplea en la oflib, usada
para convertir mensajes entre un formato de OpenFlow, que es el que usan los mensajes
que viajan por la red, a un formato Host, para una manipulación más fácil. Mientras que
es posible utilizar estructuras de la oflib para crear y enviar mensajes, la creación y env´ıo
de los mensajes basados en TLV con OpenFlow 1.3 son tareas más complejas. As´ı que
para facilitar esto se realiza de la forma siguiente,
Flow f;
uint32_t in_port=2;
uint32_t out_port=1;
f.Add_Field("in_port", in_port);
Actions *acts = new Actions ();
acts -> CreateOutput (out_port);
Instruction *inst = new Instruction ();
inst -> CreateApply(acts);
FlowMod *mod = new FlowMod(0x00ULL,0x00ULL, 0, OFPFC_ADD, 1,
OFP_FLOW_PERMANENT, OFP_DEFAULT_PRIORITY, in -> buffer_id,
OFPP_ANY, OFPG_ANY, ofd_flow_mod_flags());
mod -> AddMatch(&f.match);
mod -> AddInstructions (inst);
30

En el ejemplo anterior se crea un mensaje flow mod, con un campo in port para que
coincida con cada paquete de entrada por el puerto 2; también se define la acción para
mandar todos los paquetes que coincidan por el puerto 1.
Para enviar ya mensaje que se ha creado anteriormente, se debe usar el método,
send openflow msg, que se encarga del env´ıo de cualquier mensaje.
send_openflow_msg(pi.dpid, (struct ofl_msg_header *)
&mod->fm_msg, 0, true);
Por ejemplo para especificar Vlans, hay que determinar dos campos, vlan id y vlan
priority. Para ello se utiliza el comando flow mod, cuyo objetivo es añadir, modificar y
eliminar flujos.
flow_mode={ table="0", cmd="add", cookie="0x0", mask="0x0", idle="30",
hard="300", prio="2048", buf="none", port="any", group="any",
flags="0x0", match=oxm{in_port="2", eth_type=0x"800"},
insts="[apply{acts=[out{port="1"}]}]};
En este proyecto, se ha desarrollado a partir de un ejemplo, “discovery”, modificando
su código para poder conectarse a la aplicación web (monitor web).
La comunicación se establece a través de un socket. Un socket es la forma de intercambio
de flujos de datos entre dos programas, generalmente de manera fiable y ordenada. Utiliza
los protocolos TCP/IP a través de una API, proporcionada por el sistema operativo.
Un socket se define por un par de direcciones IP local y remota, un protocolo de trans-
porte y un par de números de puertos, uno local y otro remoto.
Hay dos formas de implementar un socket,
Cuando se implementa con el protocolo TCP, se caracteriza ser orientado a la cone-
xión, garantizando la transmisión sin errores y llegada de los paquetes a su destino
y con el mismo orden de salida.
La implementación UDP se caracteriza por no estar orientado a la conexión, sin
garatizar la correcta llegada de los paquetes, ni el orden correspondido.
El evento dp join handler se lanza cuando se une un nuevo dispositivo. En ese mo-
mento se crea un nuevo socket, por le que se env´ıa la información del router como la
DPID y la MAC a la base de datos.
En el momento que se desconecta un dispositivo, se lanza el evento dp leave handler,
en el que se env´ıa el DPID del dispositivo, para indicar que no está activo.
La idea de esta aplicación web es monitorizar todo aquello que suceda en la red Open-
Flow, desde los dispositivos que se conectan a la red, los puertos disponibles del router
(habilitados para OpenFlow), hasta los mensajes que se mandan entre el controlador y los
dispositivos. Como se explica en el siguiente apartado uno de los objetivos de la aplicación
31

es enviar las reglas desde la página web al controlador.
El funcionamiento de NOX como se puede observar en los ejemplos comentados, es a
través de eventos; esto quiere decir que cualquier suceso que llega al controlador, como la
conexión de un dispositivo o su desconexión, genera un evento en concreto, que permite
controlar este suceso.
Figura 13: Diagrama de eventos NOX
En la Figura 13 se observa un diagrama de como funcionan los eventos en NOX y al
programa desarrollado,
1. Petición TCP, la configuración OpenFlow del router inicia una conexión TCP con
el controlador; en caso de no estar lo reintenta tantas veces, hasta que consigue
conectarse.
2. Evento dp join handler, es el evento que lanza NOX cuando se conecta cualquier
dispositivo. Este evento, en el programa desarrollado, realiza tres pasos,
a) Recibe la información del router,
b) Env´ıa la configuración inicial al router,
c) Env´ıa los datos del router a la web.
3. Se guardan los datos en la base de datos.
4. Se env´ıa las reglas asignadas a ese puerto o IP, si tiene asignada alguna acción.
5. Se produce la desconexión del router, lo que puede deberse a diferentes motivos.
6. El controlador lanza el evento dp leave handler, el cuál se encarga de enviar el DPID
a la base de datos.
7. Indica en la base de datos que ese dispositivo no está disponible.
32

3.4. Pruebas
En este apartado se explican las pruebas realizadas sobre la maqueta desplegada.
La primera prueba permite analizar la conexión inicial entre los router y el controlador.
Con la herramienta Wireshark se captura el tráfico correspondiente.
Figura 14: Captura inicial de la comunicanción
Como se observa en la Figura 14, el router intenta establecer una conexión TCP con el
controlador; al no estar todav´ıa activo, el switch reintenta la conexión cada cierto tiempo.
Este tiempo de espera crece de manera exponencial. Como se observa el tiempo para en
el primer reintento es 2 segundos, en el segundo 4 segundos y en el tercero 8 segundos.
Una vez establecida la conexión TCP, el controlador env´ıa el tipo de mensaje HELLO
al router, y este contesta con otro mensaje HELLO. Este mensaje sirve para mantener
activa la conexión.
También se observa que el puerto que siempre utiliza el controlador es el 6633, pero
el usuado por el router var´ıa por cada petición TCP que se abre.
A continuación se muestra un diagrama, en la Figura 15, la comunicación inicial es-
tablecida.
33

Figura 15: Diagrama de conexión inicial
La siguiente captura, Figura 16, comprueba los parámetros del router, las acciones,
atributos del router, etc. El mensaje OpenFlow es OFPT FEATURES REQUEST, y la
respuesta del router es OFPT FEATURES REPLY. El controlador también env´ıa un
mensaje con la configuración inicial del router OFPT SET CONFIG.
34

Figura 16: Captura de la configuración del router
La primera trama la env´ıa el controlador al dispositivo correspondiente con la IP
192.168.1.2, esta configuración se define inicialmente en el controlador. En la segunda
trama los parámetros de configuración(segunda imagen de la Figura 16) y la última la
respuesta que realiza el dispositivo al controlador indicando su configuración (primera
imagen de la Figura 16).
El diagrama de la Figura 17 se muestra como se configura inicialmente el router,
35

Figura 17: Diagrama de configuración
Otro mensaje importante en el protocolo OpenFlow es OFPT FLOW MOD, cuyo ob-
jetivo, es crear, modificar o eliminar acciones en la tabla del switch. Este es el mensaje
utilizado para crear las VLAN.
En el momento, en el que se desconecta un dispositivo, como se muestra en la Figura
18, por cualquier razón, el controlador env´ıa el mensaje OFPT ECHO REQUEST para
comprobar que el dispositivo sigue activo, si el controlador no recibe respuesta con el
mensaje OFPT ECHO REPLY, el controlador lo interpreta como que esta desconectado
y no lo vuelve a intentar. En la Figura 18 se muestra la desconexión del dispositivo con
la dirección IP 192.168.1.2.
36

Figura 18: Desconexión de un dispositivo, desde el Wireshark
Se realizan cuatro intentos y al no recibir una respuesta, el controlador no lo vuelve a
intentar. La Figura 19 muestra, muestra el momento en que el controlador se descontrola
mostrando una mensaje por consola.
Figura 19: Desconexión de un dispositivo, desde el punto de vista del controlador
En el punto uno de la Figura 19, se muestra un intento de conectar con el dispositivo,
en el dos es el último intento que realiza el controlador y pasa a desconectar el dispositivo.
Y por último confirma la desconexión del dispositivo por parte del controlador.
37

4. Desarrollo de una interfaz web Openflow
Se explica la interfaz web desarrollada en este proyecto, su objetivo, las tecnolog´ıas
que se han utilizado y aspectos básicos de su desarrollo.
4.1. Introducción
En este proyecto se ha incorporado un módulo más para completar el controlador. Se
desarrolla un monitor web, cuyo objetivo es saber el estado en el que se encuentra la red
OpenFlow, es decir, si se ha producido un algún fallo, que caracter´ısticas tiene la red, que
dispositivos componen la red, la topolog´ıa de la red, etc. Además incluye una función que
permite interactuar la página web con el controlador, cuyo objetivo es enviar las reglas
desde la pagina web al controlador, lo que facilita la administración de la red.
La finalidad de este módulo es muy sencillo, hoy en d´ıa, lo que se intenta es acceder
a cualquier sitio, desde cualquier lugar, por ejemplo, si se tiene que acceder a unos ar-
chivos desde tu ordenador en otro ordenador o realizar una transferencia y no se puede
ir al banco, una posible solución a esto es a través de las aplicaciones web. Un usuario
desde su casa puede hacer la transferencia sin tener que ir al banco gracias a Internet y al
servicio web que ofrece el banco. Estas aplicaciones están disponibles las 24 horas al d´ıa
los 365 d´ıas del año. Por lo tanto se ha desarrollado este monitor para facilitar la admi-
nistración de la red desde la cuál accede desde cualquier lugar para ver el estado de la red.
Este monitor desarrollado con HTML, CSS ,jQuery y PHP. Estos son lenguajes se utilizan
para la programación web, tanto la parte del servidor como la parte del cliente. A parte
se ha creado una base de datos para guardar la información que trata el NOX. Esta base
de datos se ha implementado en MySQL. Todo esto se explicará mas adelante tanto con
ayuda de unos ejemplos.
El monitor puede ser de una gran envergadura y puede llegar a ser muy complejo, por lo
que se ha desarrollado una pequeña parte para este proyecto.
La pagina web obtiene la información de la base de datos a través de un script PHP,
pero estos datos no los guarda el controlador directamente si no un ”demonio”, el cuál
se denomina Conector (que se explica mas adelante), cuyo objetivo es el intercambio de
información entre el controlador y la pagina web. Este conector guarda la información que
env´ıa el controlador a la base de datos y env´ıa la información (las reglas) de la pagina web
al controlador. Este controlador está desarrollado en C++ y transmite la información a
través de sockets. Como gestor de base de datos utiliza MySQL.
4.2. Software
Este módulo se compone de dos partes; la página web y el Conector que se ha comen-
tado anteriormente.
La página web se compone de tres módulos (sigue el patrón MVC, Figura 20), el compo-
38

nente que el usuario se implementa en HTML, CSS, jQuery. En un segundo componente
donde se implementa todo lo referente a la lógica de control de la aplicación.
Figura 20: MVC de una aplicación web
La parte del servidor se desarrolla en PHP, utilizando un servidor apache. Y por
último, el módulo modelo, donde se implementa todo lo relativo a la lógica de negocio, es
decir, los aspectos particulares del problema que la aplicación resuelve. Además se utiliza
una base de datos, donde se almacenan los datos que se env´ıan desde el controlador NOX.
Leguajes y herramientas utilizadas
HTML (HyperText Markup Languag) es el lenguaje para la elaboración de páginas
web. Es un estándar de la W3C, organización dedicada a la estandarización de casi todas
las tecnolog´ıas ligadas a la web. Un página básica (.html) tiene la siguiente estructura,
<HTML>
<HEAD>
Aqu´ı se insertan los scripts o librer´ıas necesarias para que
la página funcione correctamente.
</HEAD>
<BODY>
Esto es el cuerpo de la página, todo lo que se muestre aqu´ı es
lo que visualiza el usuario.
</BODY>
</HTML>
Los CSS (Cascading Style Sheets) o hojas de estilo en cascada,es decir, indican el aspecto
que tiene una página web. Hacen referencia a lo objetos que aparecen en la página web,
como por ejemplo al body,p,a,etc. Los CSS tiene una sintaxis muy sencilla, como pone
de manifiesto el documento CSS(.css) que se ve a continuación.
body{
39

propiedad : valor;
}
#id{
propiedad : valor;
}
.class{
propiedad : valor;
}
Jquery es una biblioteca de JavaScript, que permite interactuar con los elementos
HTML, manejar eventos, desarrollar animaciones y utilizar la técnica AJAX en las pági-
nas web. Es software libre y de código abierto.
Un ejemplo de un fichero jQuery (.js), ser´ıa el siguiente,
$(document).ready(function() {
alert("hola mundo");
});
Este ejemplo, crea una ventana que muestra el mensaje “hola mundo”.
PHP (Hypertext Pre-processor) es un lenguaje de programación, diseñado para mostrar
contenido dinámico en páginas web. Es una alternativa (software libre) a las tecnolog´ıas
ASP, JSP, CGI, etc. Para que PHP funcione se necesita un servidor Web Apache. Un
ejemplo PHP (.php) ser´ıa el siguiente,
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8" />
<title> Ejemplo básico PHP</title>
</head>
<body>
<?php
echo ’Hola mundo’;
?>
</body>
</html>
El script PHP siempre está entre las etiquetas php, para indicar al servidor que lo
interprete adecuadamente, y no como HTML.
Mysql es un gestor de bases de datos relacional, multiusuario y multihilo, de software
libre. Para la administración de la base de datos se utiliza un interfaz web denominada
phpmyadmin, lo que facilita el trabajo.
40

Aplicación web y conector
La arquitectura final de la aplicación es la siguiente,
Figura 21: Diagrama de Software
La Figura 21 muestra la interacción de la aplicación web con el controlador NOX:
1. Enviar datos del controlador NOX a conectador.
2. El conector guarda los datos en la base de datos.
3. La aplicación web muestra los datos de la base de datos.
4. La aplicación web env´ıa las reglas al conector.
5. El conector env´ıa la información del conector al controlador NOX.
En la Figura 21, aparece un nuevo elemento denominado Conector. El objetivo del
Conector es guardar la información que env´ıa a la base de datos. La conexión no se rea-
liza directamente con la aplicación, ya que se pueden producir errores con los socket (al
recargar la página, si se accede desde dos sitios a la vez, etc.). Está escrito en C++ y se
comunica con la base datos en MySql con la librer´ıa mysql connection.h y mysql driver.h .
La estructura para obtener información de la base datos con esta librer´ıa es la siguiente,
MYSQL *con;
MYSQL_RES *res;
MYSQL_ROW row;
con = mysql_init(NULL);
con = mysql_real_connect(con, IP , BD, USER, PASS, 0, NULL, 0);
41

BUSCAMOS DATOS EN LA TABLA
mysql_query(con, "SELECT * FROM tablas");
res = mysql_store (con);
//numero total de resultados
int num = mysql_num_fields(res);
//recorremos los resultados
while ( ( row = mysql_fetch_row ( res ) ) ){
/recorre los campos
for (i=0; i<num ; i++){
}
}
//INSERTAR datos
char * sql;
sql = "INSERT INTO TABLA (campo1, campo2,..) VALUES(valor1, valor2,..);
mysql_query(con,sql);
//MODIFCAR datos
char * sql;
sql = "UPDATE TABLA SET campo = valor";
//ELIMINAR datos
char * sql;
sql = "DELETE FROM TABLA WHERE campo = valor";
El ejemplo anterior es un script donde se muestran las principales funciones para
obtener los datos de la base de datos del Conector.
42

Figura 22: Diagrama del Controlador con el Conector
La Figura 22 muestra dos de los eventos que se gestionan en el controlador, y como
se env´ıan los datos del controlador al conector para que guarde la información en la base
de datos.
Figura 23: Diagrama de la web con el controlador
En la Figura 23, se indica la manera en la que se env´ıan reglas desde el monitor web
al controlador y a la base de datos.
Se observa también que la aplicación web guarda directamente las reglas en la base de
datos, sin que el controlador intervenga. De esta forma, el cliente no utiliza en ningún
momento el socket para intercambiar la información.
El funcionamiento del Controlador se basa en modelo cliente-servidor. El cliente reali-
za peticiones a un servidor, y éste le da una respuesta, como se observa en la Figura
24.
43

Figura 24: Modelo Cliente-Servidor
El Controlador está continuamente escuchando en un puerto definido y bien cono-
cido; Cuando se conecta un dispositivo al controlador, se crea un socket con la ip y el
puerto destino del controlador. El Conector crea un nuevo socket para recibir la informa-
ción enviada desde el controlador y, una vez finalizada la transmisión, se cierran los socket.
Para enviar las reglas, el Conector comprueba cada cierto tiempo (con la función sleep),
si hay una regla nueva en la base de datos y se env´ıa al controlador. Para esto se utiliza
un hilo adicional, con lo que no perjudica a la otra parte del Conector.
Se ha indicado solo dos funciones de la aplicación web, mostrar información de los dispo-
sitivos y enviar las reglas escritas. La funcionalidades que se quieren ofrecer con la página
web ser´ıan las siguientes,
Mostrar información de los dispositivos, DPID y MAC del conmutador, puertos
disponibles, etc.
Enviar las reglas al controlador, las reglas tiene que seguir una sintaxis correcta,
también se visualiza las reglas que están en curso.
Administración de usuarios, control de los usuarios que pueden acceder a la aplica-
ción.
Administración de roles, cada rol tiene unos permisos concretos.
Topolog´ıa de la red.
Visualización de los mensajes que hay en el tráfico de la red.
44

El controlador, como la aplicación web y la base de datos se pueden localizar en dife-
rentes ordenadores, ya que la transmisión de información se realiza a través de un socket.
En un socket se puede configurar la IP destino, indicando el host donde se localize el
Controlador.
A continuación se muestra una serie de capturas de la aplicación web. La aplicación
web, como se explica anteriormente no este finalizada.
La primera captura, Figura 25, es la página “login”donde el usuario se identifica, va-
lidando los datos en la base de datos.
Figura 25: Login de la aplicación
Una vez identificado el usuario, la siguiente captura, Figura 26, muestra la página
principal de la aplicación donde se muestra los dispositivos, y la topolog´ıa (aunque está no
este finalizada).
Figura 26: Página principal de la aplicación
Como se observa, en la Figura 26, la parte de la izqiuerda se muestra la lista de los
dispositivos conectados al controlador, en centro se muestra la topolog´ıa de está.
En la Figura 27, es donde se muestra la información del dispositivo, haciendo click,
en alguno de los dispositivos de la lista.
45

Figura 27: Información de los dispositivos
La ultima captura, Figura 28, es donde el usuario crea las reglas que se env´ıan al
controlador.
Figura 28: Página de creación de reglas
El código del Conector se localiza en el Anexo 2.
46

5. Conclusiones
El principal objetivo planteado en este proyecto, fue el desarrollo e integración de
una maqueta sobre protocolo Openflow. Con este fin, se realizó una investigación de las
diferentes tecnolog´ıas, A saber: redes virtuales (VN), redes definidas por Software (SDN)
y el protocolo OpenFlow.
Los principales hitos conseguidos durante el desarrollo de este proyecto son los siguientes:
Implementación exitosa de una red SDN, usando NOX como controlador y Open-
Flow como protocolo para comunicación entre los dispositivos y el controlador. Cabe
decir que existen algunos problemas asociados a la configuración de la red, particu-
larmente la actualización del firmware en los dispositivos, y su incompatibilidad de
éstos con los dispositivos debido a las diferentes versiones de protocolos.
Desarrollo de una aplicación web para la administración y gestión de la red SDN.
Además, es importante señalar que esta v´ıa de trabajo es ampiable, pudiendo abar-
car desde control de usuarios, administración de permisos, o roles hasta control de
todas las trazas del protocolo.
Por otra parte, es importante subrayar que este tipo de trabajos son aplicables a la hora
de mejorar las redes actuales, tanto como la red de Internet, como la red de una Uni-
versidad o de Empresa. Este proyecto es una contribución a la mejora de aspectos como
la eficiencia, el ahorro de costes, o la personalización de la gestión de las redes, entre otros.
Finalmente, he tenido la oportunidad de afrontar un desafio personal que me ha lle-
vado a mejorar mi conocimiento sobre redes virtuales y redes SDN, tanto desde un punto
de vista teórico como funcional. De hecho, como resultado de este trabajo se ha logrado
la implementación de ejemplos reales que han sido testados.
47

6. Bibliograf´ıa y Referencias
Referencias
[1] Página oficial de la Open Networking Foundation (ONF). Dispobible en
https://www.opennetworking.org/.
[2] Página web de NOX: Disponible en: http://www.noxrepo.org/.
[3] Stanford OpenFlow Team. Pagina web OpenFlow. Disponible en:
http://www.openflow.org/.
[4] OpenWrt Wireless Freedom, página oficial: https://openwrt.org/.
[5] OpenFlow 1.3. Página web: https://github.com/CPqD/ofsoftswitch13/wiki/OpenFlow-
1.3-for-OpenWRT.
[6] Documentación OpenFlow 1.3. Página web: https://github.com/CPqD/ofsoftswitch13/wiki/Dpctl-
Documentation.
[7] Proyecto: Mecanismos de control de las comunicaciones en la Internet de las comu-
nicaciones del futuro a través de OpenFlow.
[8] Proyecto: Implementación de un prototipo de una red definida por software (SDN)
empleando una solución basada en hardware.
48

A. Anexo 1
A.1. Tutorial OpenWrt
El primer paso es instalar las dependecia necesarias para poder crear la imagen. Las
dependecias son las siguientes,
$ sudo apt-get install build-essential binutils flex bison autoconf gettext texinfo
sharutils subversion libncurses5-dev ncurses-term zlib1g-dev gawk
El siguiente paso es descargar el paquete correspondiente, por ejemplo la siguiente:
$ svn co svn://svn.openwrt.org/openwrt/branches/backfire
$ cd backfire
Una vez, en la carpeta backfire nos disponemos a actualizar los scripts y a instalarlos.
$ ./scripts/feeds update -a
$ ./scripts/feeds install -a
Ahora pasamos a selccionar que módulos queremos instalar en la imagen de OpenWrt,
OpenFlow, Servidor FTP, servidor apache, o cualquier servicio que se necesite. Para ello
se realiza lo siguiente,
$ make menuconfig
Antes de configurar la imagen, hay que añadirle el protocolo OpenFlow, para ello se
realiza lo siguiente,
$ git clone https://github.com/CPqD/openflow-openwrt.git
$ cd package
$ ln -s ../openflow-openwrt/openflow-1.3/
$ ln -s openflow-openwrt/openflow-1.3/files
$ make menuconfig
Una vez dentro del menu, configuramos de los que queremos disponer en el dispositivo.
Seleccionamos el sistema donde se instala la imágen, en nuestro caso en Atherosxxx/9xxx
y seleccionamos el dispositivo final, como se muestra en la Figura 29.
49

Figura 29: Configuración del menu OpenWrt
Y en el menú de Network seleccionamos el protocolo OpenFlow 1.3 como se muestra
en la Figura 30.
Figura 30: Selección del protocolo OpenFlow en el menu OpenWrt
50

A continuación es compilar la imagen OpenWrt.
$ make
Y por último paso, es la actualización del firmware del router. Que para ello se tiene que
acceder al dispositivo, seleccionar la imágen correspondiente y actualizar el dispositivo.
Este proceso tarda unos minutos.
51

B. Anexo 2
B.1. Código del módulo desarrollado
El software que se ha desarrollado se divide en dos ficheros, el primero es el discovery.h
#ifndef DISCOVERY_HH
#define DISCOVERY_HH
#include <boost/shared_array.hpp>
#include <map>
#include <vector>
#include <set>
#include "component.hh"
#include "timeval.hh"
#include "link-event.hh"
#include "../../../oflib/ofl-messages.h"
#define LLDP_TTL 120
#define PER_PORT_PERIOD 100
#define PACKET_OUT_PERIOD 10
#define TIMEOUT_CHECK_PERIOD 500
#define LINK_TIMEOUT PER_PORT_PERIOD * 3
#define LLDP_TYPE 0x88cc
namespace {
using namespace vigil;
using namespace vigil::container;
class Port {
public:
Port() : dpid(datapathid()), port(0) { };
Port(const datapathid& _dpid, uint32_t _port) :
dpid(_dpid), port(_port) { };
bool operator==(const Port& p) const {
return (dpid == p.dpid) &&
(port == p.port);
}
52

bool operator!=(const Port& p) const {
return (dpid != p.dpid) ||
(port != p.port);
}
bool operator<(const Port& p) const {
if (dpid == p.dpid) {
return (port < p.port);
}
return (dpid < p.dpid);
}
datapathid dpid;
uint32_t port;
};
class Link {
public:
Link(const Port& _sport, const Port& _dport) :
sport(_sport), dport(_dport) { };
bool operator==(const Link& l) const {
return (sport == l.sport) &&
(dport == l.dport);
}
bool operator!=(const Link& l) const {
return (sport != l.sport) ||
(dport != l.dport);
}
bool operator<(const Link& l) const {
if (sport == l.sport) {
return (dport < l.dport);
}
return (sport < l.sport);
}
Port sport;
Port dport;
};
53

class Discovery : public Component {
public:
Discovery(const Context* c, const json_object*);
void configure(const Configuration *c);
void install();
private:
void send_Data(char* dir, char** datos);
Disposition packet_in_handler(const Event& e);
Disposition dp_join_handler(const Event& e);
Disposition dp_leave_handler(const Event& e);
Disposition port_status_handler(const Event& e);
void dp_add(struct ofl_msg_features_reply *features);
void escuchar();
std::set<datapathid> dps;
private:
void dp_remove(const datapathid& dpid);
void port_add(const Port& port);
void port_delete(const Port &port, Link_event::Reason reason);
std::vector<Port>::iterator port_delete(std::vector<Port>::iterator iter, Link_eve
void link_add(const Link& link);
void link_delete(const Link& link, Link_event::Reason reason);
void link_delete(std::map<Link, uint64_t>::iterator iter, Link_event::Reason reaso
void update_timeval();
void timeout_links();
void send_lldp();
std::vector<Port> ports;
std::map<Port, boost::shared_ptr<Buffer> > lldps;
std::map<Link, uint64_t> links;
size_t next_port;
uint64_t per_port;
uint64_t packet_out;
uint64_t timeout;
uint64_t link_timeout;
54

timeval per_port_tv;
timeval timeout_tv;
static Buffer *create_lldp(const Port& port, uint16_t ttl = LLDP_TTL);
static bool parse_lldp(const uint8_t *buf, size_t buf_len, Port& port);
};
} // unnamed namespace
#endif /* DISCOVERY_HH */
Y el segundo es el discovery.cc
#include <boost/bind.hpp>
#include <boost/shared_array.hpp>
#include <netinet/in.h>
#include <map>
#include <vector>
#include <set>
#include <algorithm>
#include <iostream>
#include <sys/socket.h>
#include <sys/types.h>
#include <inttypes.h>
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <signal.h>
#include <unistd.h>
#include <mysql/mysql.h>
#include <unistd.h>
#include <signal.h>
#include "discovery.hh"
#include "assert.hh"
#include "component.hh"
#include "nox.hh"
#include "packets.h"
#include "vlog.hh"
#include "timeval.hh"
#include "netinet++/ethernet.hh"
#include "openflow/openflow.h"
#include "flow.hh"
#include "openflow-default.hh"
#include "flowmod.hh"
55

#include "string.h"
#include "datapath-join.hh"
#include "datapath-leave.hh"
#include "ofp-msg-event.hh"
#include "../../../oflib/ofl-structs.h"
#include "../../../oflib/ofl-messages.h"
#define PER_PORT_ARG "per_port"
#define PACKET_OUT_ARG "pkt_out"
#define TIMEOUT_ARG "check"
#define LINK_TO_ARG "link_to"
#define IP "127.0.0.1"
#define PORT 5001
struct data{
char *dpid;
} datos;
using namespace std;
namespace {
using namespace vigil;
using namespace vigil::container;
Vlog_module lg("discovery");
Discovery::Discovery(const Context* c, const json_object*): Component(c),dps(){}
void Discovery::configure(const Configuration* c){
lg.dbg("Instalando aplicacion");
}
void Discovery::install(){
register_handler(Ofp_msg_event::get_name(OFPT_PACKET_IN), boost::bind(&Discovery::pack
register_handler(Datapath_leave_event::static_get_name(), boost::bind(&Discovery::dp_l
register_handler(Ofp_msg_event::get_name(OFPT_PORT_STATUS), boost::bind(&Discovery::po
register_handler(Datapath_join_event::static_get_name(), boost::bind(&Discovery::dp_jo
56

}
Disposition Discovery::packet_in_handler(const Event& e) {
const Ofp_msg_event& pi = assert_cast<const Ofp_msg_event&>(e);
struct ofl_msg_packet_in *in = (struct ofl_msg_packet_in *)**pi.msg;
Flow *flow = new Flow((struct ofl_match*) in->match);
uint16_t dl_type;
flow->get_Field<uint16_t>("eth_type",&dl_type);
if (dl_type == ethernet::LLDP){
return CONTINUE;
}
uint8_t eth_src[6];
flow->get_Field("eth_src", eth_src);
/*printf("Origen: %02x:%02x:%02x:%02x:%02x:%02xn",
eth_src[0] & 0xff, eth_src[1] & 0xff, eth_src[2] & 0xff,
eth_src[3] & 0xff, eth_src[4] & 0xff, eth_src[5] & 0xff);
// printf("MAC origen: %" PRIu8 "n", eth_src);
*/
return CONTINUE;
}
Disposition
Discovery::dp_join_handler(const Event& e) {
const Datapath_join_event& dpj = assert_cast<const Datapath_join_event&>(e);
printf("switch DPID: %"PRIx64"n",dpj.dpid.as_host());
char datos[100];
sprintf(datos,"%" PRIx64,dpj.dpid.as_host());
//mandamos a la interfaz el codigo
int fd, numbytes;
struct hostent *he;
struct sockaddr_in server;
fd = socket(PF_INET,SOCK_STREAM, 0);
if (fd < 0 )
{
lg.dbg("Error en socket");
}
57

if ((he = (hostent*) gethostbyname("127.0.0.1"))== NULL){
lg.dbg("Error getHost");
}
server.sin_family = AF_INET;
server.sin_port = htons(5000);
server.sin_addr = *((struct in_addr *)he->h_addr);
bzero(&(server.sin_zero),8);
if (connect(fd, (struct sockaddr *)&server, sizeof(struct sockaddr)) == -1){
lg.dbg("error en conectar");
}
if (send(fd,datos,100, 0) == -1){
lg.dbg("Error en send");
}
close(fd);
uint32_t in_port = 2;
uint32_t out_port = 4;
Flow *f = new Flow();
f->Add_Field("in_port",in_port);
Actions *acts = new Actions();
acts->CreateOutput(out_port);
Instruction *inst = new Instruction();
inst->CreateApply(acts);
FlowMod *mod = new FlowMod(0x00ULL,0x00ULL, 0,OFPFC_ADD, OFP_FLOW_PERMANENT, OFP_
OFPP_ANY, OFPG_ANY, ofd_flow_mod_flags());
mod->AddMatch(&f->match);
mod->AddInstructions(inst);
send_openflow_msg(dpj.dpid, (struct ofl_msg_header *)&mod->fm_msg, 0/*xid*/, true
dp_add((struct ofl_msg_features_reply *)**dpj.msg);
return CONTINUE;
}
Disposition
Discovery::dp_leave_handler(const Event& e) {
lg.dbg("Se ha desconectado: enviando ...n");//, &e.get_name());
//printf("%sn",&e.get_name());
return CONTINUE;
58

}
Disposition
Discovery::port_status_handler(const Event& e) {
lg.dbg("EVENTO3: n");//, &e.get_name());
return CONTINUE;
}
void Discovery::dp_add(struct ofl_msg_features_reply *features) {
datapathid dpid = datapathid::from_host(features->datapath_id);
if (dps.find(dpid) != dps.end()) {
lg.warn("Joined DP was already registered!");
//dp_remove(dpid);
}
dps.insert(dpid);
}
void Discovery::send_Data( char* dir, char** datos){
}
void Discovery::escuchar(){
lg.dbg("Creado el hijo...n");
struct sockaddr_in cliente;
int sin_size;
int numbytes;
int fd, fd2;
char buffer [1000000000];
if ((fd=socket(AF_INET, SOCK_STREAM, 0)) == -1){
lg.warn("error en socket()n");
} else{
lg.dbg("Socket creado...n");
59

}
server.sin_addr.s_addr = inet_addr("127.0.0.1");
if(bind(fd,(struct sockaddr*)&server,sizeof(struct sockaddr))==-1) {
lg.warn("error en bind() n");
} //fin if
if(listen(fd,2) == -1) {
lg.warn("error en listen()n");
} //fin if
else{
lg.dbg("Escuchando...n");
}
while(1){
lg.dbg("esperando...n");
sin_size = sizeof( struct sockaddr_in );
if ((fd2 = accept(fd,(struct sockaddr *)&cliente,(socklen_t*)&sin_size)) == -1){
lg.warn ("error en acept");
}else{
lg.dbg ("Conexi´on aceptada");
}//fin if
if ((numbytes = recv(fd2, buffer,1000000000,0)) == -1){
lg.warn("Error en recvn");
}
printf("REGLA: %sn",buffer);
}//fin while
}//fin function
REGISTER_COMPONENT(container::Simple_component_factory<Discovery>, Discovery);
}
60

B.2. Código del Controlador
Se ha creado un script denominado conexion.sh para compilar y ejecutar el Controla-
dor. Para ejecutar dicho script se realiza de la siguiente manera,
$ ./conexion.sh
Y el código es el siguiente,
/***************** SCRIPT ********************/
#!/bin/bash
gcc -o demonioProyecto.o interfaz.c ‘mysql_config --cflags‘ ‘mysql_config --libs‘
./demonioProyecto.o
A continuación, el código del Conector.
/************** Código del Conector *********/
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <mysql/mysql.h>
#include <arpa/inet.h>
#include <stdio.h>
#include <my_global.h>
#include <pthread.h>
#include <string.h>
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <netdb.h>
#include<stdlib.h>
//void check();
void check(){
MYSQL *con2;
MYSQL_RES *res;
MYSQL_ROW row;
con2 = mysql_init(NULL);
if (!con2)
{
printf("Conexion 2 no establecidan");
61

}else{
//conexi´on de la base de datos
con2 = mysql_real_connect(con2,"127.0.0.1","proyecto","proyecto", "proyecto",0,NULL,0)
if (!con2)
{
printf("Conexion 2 no establecidan");
}else{
printf("Conexion 2 establecidan");
}
while (1){
int i =0;
if (mysql_query(con2,"SELECT * FROM reglas")) {
printf("%sn", mysql_error(con2));
mysql_close(con2);
}
res= mysql_store_result(con2);
if (res == NULL){
printf("%sn", mysql_error(con2));
mysql_close(con2);
}
while ((row = mysql_fetch_row(res))){
for (i=0;i< num ; i++){
if (i == 2){
if (strncmp(row[i],"0",1)== 0){
//enviar reglas
char * sql= malloc(500);
strcpy(sql, "UPDATE reglas SET enviado = 1 WHERE id = ");
strcat(sql,row[0]);
mysql_query(con2,sql);
mysql_close(con2);
int fd, numbytes;
62

fd = socket(PF_INET,SOCK_STREAM, 0);
if (fd < 0 )
{
perror("Error en socket");
}
/* if ((he = (hostent *) gethostbyname("127.0.0.1"))== NULL){
perror("Error getHost");
}*/
while (connect(fd, (struct sockaddr *)&server, sizeof(struct sockaddr)) == -1){
printf("esperando a conectar...n");
}
if (send(fd,row[1],1000000000, 0) == -1){
perror("Error en send");
}else {
printf("Datos enviadosn");}
close(fd);
} //fin comp
} //fin if
}//fin for
}//fin while
sleep(5000);
}//fin bucle infinito
}//fin if conexion
}//fin check
main()
{
MYSQL *con;
MYSQL_RES *res;
int fd,fd2;
63

struct sockaddr_in cliente;
int sin_size;
char buffer [1000];
int numbytes;
pthread_t thread;
pthread_t check_t;
pthread_create (&thread, NULL, check, NULL);
if ((fd = socket(AF_INET, SOCK_STREAM, 0)) == -1){
printf("Error en socketn");
}
if (bind(fd,(struct sockaddr*)&server,sizeof(struct sockaddr)) == -1){
perror("error en bindn");
}else
{
printf("crear bindn");
}
if (listen(fd,2) == -1){
printf("Error listenn");
}
while(1){
sin_size = sizeof( struct sockaddr_in);
if ((fd2 = accept(fd,(struct sockaddr *)&cliente,(socklen_t*)&sin_size)) == -1){
printf("eRROR ACEPT");
}else{
printf("Conexion aceptadan");
}
64

if ((numbytes = recv(fd2, buffer,1000,0)) == -1){
perror("Error en recvn");
}
printf("Guardando en bbddn");
con = mysql_init(NULL);
if (!con)
{
printf("Conexion no establecidan");
}else{
printf("Conexion establecidan");
}
con = mysql_real_connect(con,"127.0.0.1","proyecto","proyecto", "proyecto",0,NULL,0);
if (!con)
{
printf("Conexion no establecidan");
}else{
printf("Conexion establecidan");
}
char * sql= malloc(1000);
strcpy(sql, "SELECT * FROM dispositivos WHERE idDisp =’");
strcat(sql,buffer);
strcat(sql,"’");
printf("SQL: %sn",sql);
if (mysql_query(con, sql)) {
}
res= mysql_store_result(con);
if (res == NULL){
printf("%sn", mysql_error(con));
mysql_close(con);
}
if (num > 0){
65

printf("PID: %s ya esta guardado n",buffer);
}
//Guardas la informacion del dispositivo
printf("PID: %sn",buffer);
strcpy(sql, "INSERT INTO dispositivos (idDisp) VALUES (’");
strcat(sql,buffer);
strcat(sql,"’)");
printf("SQL: %sn",sql);
if (mysql_query(con, sql)) {
printf("%sn", mysql_error(con));
mysql_close(con);
}else {
printf("Datos guardadosn");
}
}
}
La dirección IP 127.0.0.1, hace referencia a la máquina local, es decir, que la base de
datos se localiza en el mismo equipo donde esta el Conector. Sin embargo si la base de
datos se encuentra en otro equipo, se tendr´ıa que poner la IP correspondiente del equipo
y los datos necesarios para conectar con la base de datos.
B.3. Código de la aplicación web
La aplicación web consta de múltiples ficheros, css, js, php, html, etc. Los principales
ficheros son los siguientes,
/************ index.html **************/
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Under The Bridge</title>
66

<input type="text" id="pass" placeholder="Pass">
</div>
<div id="errorMessage"></div>
<div id="botones">
<center><input id="btnAceptar" value="Aceptar" type="button" onclick="checkLogin();"><
</div>
</div>
</form>
</body>
</html>
En esta página realiza la validación del usuario para acceder a la aplicación.
/**************** PÁGINA principal.php ***********/

<head>
<?php
include ’funciones.php’;
?>
<title>Monitor NOX</title>
<script src="js/jquery.modal.js" type="text/javascript"></script>
<link href="css/jquery.modal.css" rel="stylesheet" type="text/css" media="all" />

</head>
<body>
<div id="wrapper">
68

<div id="menu" class="container">
<ul>
<li class="current_page_item"><a href="#">Dispositivos</a></li>
<li><a href="reglas.php">Reglas</a></li>
<li><a href="#admin">Admin</a></li>

</ul>
</div>

<div id="header" class="container">
<div id="colum" style="width: 150px; border:1px solid #000 ;height: 505px;">
<table>
<th>Dispositivos</th>
<hr>
<?php
$disp=array();
$disp=buscarDisp();
for ($i=0;$i<count($disp);$i++){
?><tr><td><a href="#modalInfor" id="refDisp" rel="modal:open">
<?php
echo($disp[$i]);
?>
</a>
</td>
</tr>
<?php
}
?>
</table>
</div>
<div class="contenido">
</div>
</div>
<div id="modalInfor" style="display:none;" class="login_form modal">
<p>Informaci´on del dispositivo.</p>
<a href="#" rel="modal:close">Cerrar</a>
</div>
<div id="footer-wrapper">
<div id="footer" class="container">
</div>
69

</div>
</body>
</html>
En la anterior se muestran los dispositivos y la topolog´ıa de la red.
La siguiente se muestra el panel para insertar las reglas, para enviarlas al controlador.
/**************** reglas.php ******************/

<head>
<?php
include ’funciones.php’;
?>
<title>Monitor NOX</title>
<script src="js/jquery.modal.js" type="text/javascript"></script>
<link href="css/jquery.modal.css" rel="stylesheet" type="text/css" media="all" />pue

<script type="text/javascript">
function guardarRegla()
{
alert($("#AreaReglas").val());
70

$.ajax({
url: "sw.php",
type: "POST",
data: {
tipo: "regla",
texto: $("#AreaReglas").val()
},
success: function(response)
{
if(response == 1)
{
}
else
{
}
}
});
}
</script>
<body>
<div id="wrapper">
<div id="menu" class="container">
<ul>
<li><a href="principal.php">Dispositivos</a></li>
<li class="current_page_item"><a href="#">Reglas</a></li>
<li><a href="#admin">Admin</a></li>

</ul>
</div>

<div id="header" class="container" >
<div id="colum" style="width: 150px; border:1px solid #000 ;height: 500px; float:left;
<table>
<th>Dispositivos</th>
<hr>
<?php
$disp=array();
$disp=buscarDisp();
for ($i=0;$i<count($disp);$i++){
?><tr><td><a href="#modalInfor" id="refDisp" rel="modal:open">
<?php
echo($disp[$i]);
?>
71

</a>
</td>
</tr>
<?php
}
?>
</table>
</div>
<div class="contenido" style="float:left; margin-left:90px; margin-top:15px;">
<form id="frmReglas">
<textarea name="reglas" rows="25" cols="120" id="AreaReglas"></textarea>
<div><center><input type="button" value="Enviar" onclick="guardarRegla();"></center></
</form>
</div>
</div>
</div>
</body>
</html>
El siguiente ﬁchero son funciones que interactuan con la base de datos, para comprobar
o guardar datos.
/************ sw.php ********************/
<?php
//include "funciones.php"
//
if ( isset($_POST["username"]) && isset($_POST["password"]))
{
/*echo conectarBBDD();
return $con;
//return login($con,$_POST[’username’],$_POST[’password’]);
*/
$con = mysql_connect(’127.0.0.1’, ’proyecto’, ’proyecto’)
or die(’No se pudo conectar: ’ . mysql_error());
mysql_select_db(’proyecto’) or die(’No se pudo seleccionar la base de datos’);
$aux= login($con,$_POST[’username’],$_POST[’password’]);
if ($aux==0)
{
echo false;
}else {
echo true;
72

}
}
if ( isset($_POST[’tipo’]) && $_POST[’tipo’] == "regla"){
$texto = $_POST[’texto’];
$con = mysql_connect(’127.0.0.1’, ’proyecto’, ’proyecto’)
or die(’No se pudo conectar: ’ . mysql_error());
mysql_select_db(’proyecto’) or die(’No se pudo seleccionar la base de datos’);
$query = "INSERT INTO reglas (texto,enviado) VALUES (’$texto’ , 0) ";
$resul = mysql_query($query);
if (!$resul)
echo( mysql_error());
else
echo false;
}
function login($con,$user,$pass){
$query = "SELECT * FROM users WHERE name =’$user’ AND pass = ’$pass’ ";
$resul = mysql_query($query);
$numero_filas = mysql_num_rows($resul);
return $numero_filas;
}
?>
Los script js, est´an incluidos en la p´agina web, pero las librerias necesarias para eje-
cutar esos script como, la jQuery se incluye en la carpeta js.
La hoja de estilos utilizada es la siguiente,
/************************* default.css ****************************/
html, body {
height: 100%;
}
body {
margin: 0px;
padding: 0px;
background: #171717;
73

font-family: ’Source Sans Pro’, sans-serif;
font-size: 12pt;
font-weight: 300;
color: #363636;
}
h1, h2, h3 {
margin: 0;
padding: 0;
}
p, ol, ul {
margin-top: 0px;
}
p {
line-height: 190%;
}
strong {
}
a {
color: #171717;
}
a:hover {
text-decoration: none;
}
a img {
border: none;
}
.image
{
display: inline-block;
}
.image img
{
display: block;
width: 100%;
}
74

.image-full
{
display: block;
width: 100%;
margin: 0 0 2em 0;
}
.image-left
{
float: left;
margin: 0 2em 2em 0;
}
.image-centered
{
display: block;
margin: 0 0 2em 0;
}
.image-centered img
{
margin: 0 auto;
width: auto;
}
hr {
display: none;
}
ul.style2
{
margin: 0;
padding: 0;
list-style: none;
}
ul.style2 li
{
border-top: solid 1px #E5E5E5;
padding: 0.80em 0;
}
ul.style2 li:first-child
{
border-top: 0;
padding-top: 0;
75

}
/*****LOGIN*****************/
#cajaLogin{
border:1px solid #fff;
border-color: white;
background-color: #3D3FFF;
width: 400px;
height: 200px;
margin: auto;
}
#errorMessage{
margin-top: 5px;
margin-bottom: 5px;
color:red;
}
#botones{
margin:auto;
padding: auto ;
}
#idUsername{
margin-top: 10px;
margin-bottom: 10px;
padding-top: 40px;
padding-left: 50px;
}
#idPass{
margin-bottom: 10px;
padding-top: 10px;
padding-left: 50px;
}
/*********************************************************************************/
/* Social Icon Styles */
76

/*********************************************************************************/
ul.contact
{
margin: 0;
padding: 3em 0em 0em 0em;
list-style: none;
}
ul.contact li
{
padding: 0em 0.30em;
font-size: 1.2em;
}
ul.contact li span
{
display: none;
margin: 0;
padding: 0;
}
ul.contact li a
{
color: #FFF;
}
ul.contact li a:before
{
background: #3f3f3f;
width: 56px;
height: 56px;
line-height: 56px;
text-align: center;
color: #FFFFFF;
}
ul.contact li a.icon-twitter:before { background: #2DAAE4; }
ul.contact li a.icon-facebook:before { background: #39599F; }
ul.contact li a.icon-dribbble:before { background: #C4376B; }
ul.contact li a.icon-tumblr:before { background: #31516A; }
ul.contact li a.icon-rss:before { background: #F2600B; }
77

/*********************************************************************************/
/* Heading Titles */
/*********************************************************************************/
.title
{
margin-bottom: 2em;
text-transform: uppercase;
}
.title h2
{
letter-spacing: 0.20em;
font-weight: 700;
font-size: 2em;
color: #171717;
}
.title .byline
{
font-weight: 400;
font-size: 0.90em;
color: #6F6F6F;
}
/** WRAPPER */
#wrapper {
background: #FFFFFF url(images/bg01.png) repeat;
}
#footer-wrapper
{
background: #0F0F0F;
}
.container {
width: 1200px;
margin: 0px auto;
}
.clearfix {
clear: both;
}
78

/*********************************************************************************/
/* Header */
/*********************************************************************************/
#header
{
position: relative;
overflow: hidden;
height: 505px;
box-shadow: 0px 0px 10px rgba(0,0,0,0.2);
}
/*********************************************************************************/
/* Logo */
/*********************************************************************************/
#logo
{
position: absolute;
top: 14em;
right: 5px;
padding: 1em 3em;
background: rgba(0,0,0,0.2);
text-shadow: -1px -1px 0 rgba(0,0,0,1);
z-index: 10;
}
#logo h1
{
text-align: right;
font-size: 3em;
}
#logo p
{
color: #FFFFFF;
}
#logo a
{
79

color: #FFFFFF;
}
/*********************************************************************************/
/* Banner */
/*********************************************************************************/
#banner
{
position: absolute;
left: 0;
overflow: hidden;
z-index: 1;
}
#banner .image
{
border: 5px solid #FFFFFF;
}
/** MENU */
#menu {
overflow: hidden;
margin-bottom: 2em;
background: #FFF;
box-shadow: 0px 0px 10px rgba(0,0,0,0.2);
height: 100px;
}
#menu ul {
margin: 0;
padding: 0px 0px 0px 0px;
list-style: none;
line-height: normal;
text-align: center;
}
#menu li {
}
#menu a {
display: block;
letter-spacing: 1px;
80

line-height: 100px;
padding: 0 40px;
text-align: center;
font-size: 0.80em;
font-weight: 600;
border: none;
color: #3D3D3D;
}
#menu a:hover, #menu .current_page_item a {
background: #F5F5F5;
}
#menu .current_page_item a {
background: #F5F5F5;
}
/** PAGE */
#page
{
position: relative;
overflow: hidden;
padding: 6em 0em 5em 0em;
}
/** CONTENT */
#content
{
float: left;
width: 790px;
}
/*********************************************************************************/
/* Sidebar */
/*********************************************************************************/
#sidebar
{
float: right;
width: 345px;
}
81

#sidebar .title h2
{
font-size: 1.6em;
}
#sidebar .box1
{
margin-bottom: 3em;
}
/*********************************************************************************/
/* Footer */
/*********************************************************************************/
#footer
{
overflow: hidden;
padding: 5em 0em;
text-align: center;
color: #6F6F6F;
}
#footer h2
{
font-weight: 700;
font-size: 2.4em;
color: #FFF;
}
#footer .byline
{
font-weight: 400;
font-size: 0.90em;
color: #6F6F6F;
}
/*********************************************************************************/
/* Copyright */
/*********************************************************************************/
#copyright
82

{
overflow: hidden;
padding: 5em 0em;
}
#copyright p
{
text-align: center;
font-size: 0.80em;
color: #6F6F6F;
}
#copyright a
{
color: #8C8C8C;
}
/*********************************************************************************/
/* Welcome */
/*********************************************************************************/
#welcome
{
overflow: hidden;
padding: 5em 0em;
border-bottom: 1px solid #E5E5E5;
text-align: center;
}
#welcome h2
{
font-size: 2.6em;
}
#welcome p
{
font-size: 1.3em;
}
#welcome .byline
{
83

display: block;
padding: 0em 0em 1.5em 0em;
font-weight: 400;
font-size: 1.2em;
color: #6F6F6F;
}
A parte incluye otros ﬁcheros css, que son propios de la librer´ıa jQuery incluidos en
la carpeta css.
A parte, se incluyen im´agenes incorporadas en la carpeta images del proyecto.
84

Phase Item OpenFlow message Feature
1 Establishment OFPT_HELLO SYM
1 Switch initiates OFPT_HELLO, and then it receives OFPT_HELLO from Controller.
2 OFPT_HELLO has only ofp_header, but it can have body. Switch has to expect body, which has to be ignored.
3 Each of them(Switch/Controller) performs version negotiation using information in OFPT_HELLO
4 Even if Switch (or Controller) behaves as older version, it doesn't mention it to the oppornent.
5 If Switch doesn't have version compatibility, it sends OFPT_ERROR to Controller and terminates connection. (See Error section)
6 If Controller doesn't have version compatibility, Switch will receive OFPT_ERROR from Controller. Then...? (See Error section)
Feature check OFPT_FEATURES_REQUEST C/S
1
Switch sends back OFPT_FEATURES_REPLY when it receives OFPT_FEATURES_REQUEST.
OFPT_FEATURES_REPLY C/S 2 Reply from Switch includes:
maximum packets buffered at once (n_buffers)
number of tables (n_tables)
Switch capabilities (capabilities)
OFPC_FLOW_STATS
OFPC_TABLE_STATS
OFPC_PORT_STATS
OFPC_STP
OFPC_MULTI_PHY_TX
OFPC_IP_REASM
Supported actions by Switch (actions)
OFPAT_OUTPUT
OFPAT_SET_VLAN_VID
OFPAT_SET_VLAN_PCP
OFPAT_STRIP_VLAN
OFPAT_SET_DL_SRC
OFPAT_SET_DL_DST
OFPAT_SET_NW_SRC
OFPAT_SET_NW_DST
OFPAT_SET_TP_SRC
OFPAT_SET_TP_DST
OFPAT_VENDOR
Port definitions (for all OpenFlow ports) (struct ofp_phy_port port[x])
port_no
hw_addr
name
config
OFPPC_PORT_DOWN
OFPPC_NO_STP
OFPPC_NO_RECV
OFPPC_NO_RECV_STP
OFPPC_NO_FLOOD
OFPPC_NO_FWD
OFPPC_NO_PACKET_IN
state
OFPPS_LINK_DOWN
OFPPS_STP_LISTEN
OFPPS_STP_LEARN
OFPPS_STP_FORWARD
OFPPS_STP_BLOCK
OFPPS_STP_MASK
curr/advertised/supported/peer
OFPPF_10MB_HD
OFPPF_10MB_FD
OFPPF_100MB_HD
OFPPF_100MB_FD
OFPPF_1GB_HD
OFPPF_1GB_FD
OFPPF_10GB_FD
OFPPF_COPPER
OFPPF_FIBER
OFPPF_AUTONEG
OFPPF_PAUSE
OFPPF_PAUSE_ASYM
2 Connectivity check OFPT_ECHO_REQUEST SYM
1
Switch issues OFPT_ECHO_REQUEST (what's the trigger? when? frequency? Does Switch initiates it automatically? ... are not in the spec)
OFPT_ECHO_REPLY SYM
2
Switch sends OFPT_ECHO_REPLY when it receives OFPT_ECHO_REQUEST from Controller
Hello message
exchange
ECHO message
exchange

3 Switch sends OFPT_ECHO_REPLY with the same body on REQUEST.
4 Switch sends OFPT_ECHO_REPLY with no body when REQUEST doesn't contain any.
3 Configuration Switch configuration OFPT_SET_CONFIG C/S 1 Controller sets OFPC_SEND_FLOW_EXP when it wants Switch to initiate OFPT_FLOW_EXPIRED message.
Only when it is set, Switch issues OFPT_FLOW_EXPIRED message when the flow expires.
flag
OFPC_SEND_FLOW_EXP
2 Controller sets the packet size to be sent from Switch with OFPT_PACKET_IN
miss_send_len
3
Controller sets the Switch's behavior in case incoming IP packet is fragmented
flag
OFPC_FRAG_NORMAL (See "Flow setting" section)
OFPC_FRAG_DROP
OFPC_FRAG_REASM
OFPC_FRAG_MASK (used as a mask for the above three options)
OFPT_GET_CONFIG_REQUEST C/S
4
Switch sends back OFPT_GET_CONFIG_REPLY when it receives OFPT_GET_CONFIG_REQUEST.
OFPT_GET_CONFIG_REPLY C/S
5
Switch reflects the values which Controller sets with OFPT_SET_CONFIG message
Port configuration OFPT_PORT_MOD C/S
1
Switch changes the specified ports' characteristics as Controller commands in OFPT_PORT_MOD message. Switch issues no reply on receipt.
Non-STP-support-switch must follow the setting below, when it performs OUTPUT action to OFPP_FLOOD port.
OFPPC_PORT_DOWN
OFPPC_NO_STP
OFPPC_NO_RECV
OFPPC_NO_RECV_STP
OFPPC_NO_FLOOD
OFPPC_NO_FWD
OFPPC_NO_PACKET_IN
2
Switch changes particular parts of the characteristics as specified with OFPT_PORT_MOD mask field.
4 Statistics information OFPT_STATS_REQUEST C/S
1
Switch reports OFPT_STATS_REPLY when it receives OFPT_STATUS_REQUEST from the Controller.
OFPT_STATS_REPLY C/S 2 Switch(datapath) reports the information specified by OFPT_STATUS_REQUEST's type field.
3 Following are the types requested by Controller:
OFPST_DESC
OFPST_FLOW
OFPST_AGGREGATE
OFPST_TABLE
OFPST_PORT
OFPST_VENDOR
When Type is OFPST_DESC:
4 The OFPT_STATS_REQUEST has no Body.
5 Switch replies the following information:
Manufacturer (character)
Hardware description (character)
Software description (character)
Serial number (character)
When Type is OFPST_FLOW:
6 The OFPT_STATS_REQUEST has ofp_flow_stats_request as Body.
7 Switch shows the information about the entry specified by Controller with ofp_match field.
8 If out_port is specified by Controller, Switch shows information only about the specified port
9 The Switch's reply includes:
Time flow has been alive (duration)
Priority of the entry (priority)
idle_timeout
hard_timeout
packet_count
byte_count
actions (struct ofp_action_header)
When Type is OFPST_AGGREGATE:
10 The OFPT_STATS_REQUEST has ofp_aggregate_stats_request as Body.
11 Switch shows the information about the entry specified by Controller with ofp_match field.
12 If out_port is specified by Controller, show information only about specified port
packet_count
byte_count

flow_count
When Type is OFPST_TABLE:
Name of the table (name)
Wildcards supported by the table (wildcards)
max number of entries (max_entries)
number of active entries (active_count)
number of packets looked up in the table (lookup_count)
number of packets that hit the table (matched_count)
When Type is OFPST_PORT:
rx_packets
tx_packets
rx_bytes
tx_bytes
rx_dropped
tx_dropped
rx_errors
tx_errors
rx_frame_err
rx_over_err
rx_crc_err
collisions
18 When Switch doesn't support particular fields, Switch sends back the fields with all '1's.
When Type is OFPST_VENDOR:
19 The OFPT_STATS_REQUEST has ofp_aggregate_stats_request as Body.
20 The other parts are vendor-defined.
5 OFPT_PORT_STATUS ASYNC
1
When a port is added, Switch Sends OFPT_PORT_STATUS with:
OFPPR_ADD
port information (struct ofp_phy_port)
2 When a port is removed, Switch sends OFPT_PORT_STATUS with:
OFPPR_DELETE
3
OFPPR_MODIFY
6 Action types OFPT_PACKET_IN ASYNC
1
Switch initiates OFPT_PACKET_IN when an incoming packet doesn't match any entries on any tables.
2
Switch initiates OFPT_PACKET_IN when corresponding action for the flow-matched entry mentions to send it to Controller (OFPP_Controller).
3 Switch includes Buffer ID in OFPT_PACKET_IN as follows:
Buffer id (ID for the potion of the packet or 0xFFFF for entire packet)
4
Switch can send fraction of packet (size of miss_send_len) + buffer ID
5 Switch can send entire packet + buffer ID of 0xffff.
OFPT_PACKET_OUT C/S
6
Switch sends packet out to the port mentioned in OFPT_PACKET_OUT, which include all or fraction of data and buffer_id
7
When buffer_id in OFPT_PACKET_OUT is 0xffff, Switch sends all the data contained in OFPT_PACKET_OUT
8
7 Flow setting Flow table setting OFPT_FLOW_MOD C/S 1 When Switch receives OFPT_FLOW_MOD, it parses the contents and set parameters accordingly.
The parameters include:
matching entry (struct ofp_match match)
ADD/MODIFY/MODIFY_STRICT/DELETE/DELETE_STRICT (command)
idle_timeout
hard_timeout
priority
buffer_id
outport for OFPFC_DELETE/DELETE_STRICT commands. OFPP_NONE or particular port number. (out_port)
zero or more actions (struct ofp_action_header actions)
When command is OFPFC_ADD:
2
Status change
notification
When a port configuration is changed (LINK UP/DOWN、802.1D port state), Switch sends OFPT_PORT_STATUS with:
Packet forwarding
action
Switch writes OFPR_NO_MATCH in the reason field of OFPT_PACKET_IN.
Switch writes OFPR_ACTION in the reason field of OFPT_PACKET_IN.
When buffer_id in OFPT_PACKET_OUT is set, Switch sends internally-buffered data to the port (buffered when Switch sends OFPT_PACKET_IN to Controller
with associated buffer_id.)
In wildcard mode, when table already has matching entry and has the same priority, Switch rejects the new message and send back OVERLAP
error message to the Controller.

3
When command is OFPFC_MODIFY:
4 If Switch doesn't have matching entry information yet, it adds the flow to the table.
5 If Switch already has matching entry information, it overwrites the action to the table.
6 Switch doesn't clear the corresponding counters.
7 If out_port is specified by Controller, Switch modifies the action only when output port is also matched.
When command is OFPFC_MODIFY_STRICT:
8 Switch modifies action only when both entry and priority are matched
9 Switch doesn't clear the corresponding counters.
10 If out_port is specified by Controller, modify the action only when output port is matched.
11 matching entry (struct ofp_match match)
match fields include:
PHY PORT # (in_port)
MAC SRC (dl_src)
MAC DST (dl_dst)
VLAN (dl_vlan)
Ethernet frame type (dl_type)
Network protocol (nw_proto)
IP SRC (nw_src)
IP DST (nw_dst)
TP SRC (tp_src)
TP_DST (tp_dst)
ICMP TYPE (tp_src)
ICMP CODE (tp_dst)
12 tp_src and tp_dst must be zero if Controller wants Switch to match fragmented IP packets
13 Switch assumes tp_src and tp_dst as ICMP_TYPE and ICMP_CODE when nw_proto is ICMP.
Switch supports various Ethernet types
14 Ethernet II
15 SNAP
dl_type=0x5FF is used for 802.3 matching
16
match field also includes wildcards fields which consist of:
17 PHY PORT # (in_port)
18 MAC SRC (dl_src)
19 MAC DST (dl_dst)
20 VLAN (dl_vlan)
21 Ethernet frame type (dl_type)
22 Network protocol (nw_proto)
23
IP SRC (nw_src) with netmask support
24
IP DST (nw_dst) with netmask support
25 TP SRC (tp_src)
26 TP_DST (tp_dst)
27 ICMP TYPE (tp_src)
28 ICMP CODE (tp_dst)
29
everything (ALL)
When command is either OFPFC_ADD, OFPFC_MODIFY, OFPFC_MODIFY_STRICT:
action field includes:
OFPAT_OUTPUT
30
OFPP_ALL
31
OFPP_Controller
32 OFPP_LOCAL
33 OFPP_TABLE -- Perform actions in flow table only for packet_out message
34 OFPP_IN_PORT
35 OFPP_NORMAL
36 OFPP_FLOOD
37 OFPP_NONE
38
PORT (not exceeding OFPP_MAX)
39 OFPAT_SET_VLAN_VID
When VLAN ID already exists, Switch replaces it with new one.
When VLAN ID doesn't exist, Switch adds it with VLAN PCP 0x0
When table is full, Switch sends back OFPT_ERROR - OFPET_FLOW_MOD_FAILED - OFPFMFC_ALL_TABLES_FULL to Controller. (See
Error section)
When IP packet is fragmented on the condition where OFPC_FRAG_NORMAL is set, the packet will be looked up. TP_SRC and TP_DSP must
be zero in order to match (as described above).

40 OFPAT_SET_VLAN_PCP
When VLAN PCP already exists, Switch replaces it with new one.
When VLAN PCP doesn't exist, add it with VLAN ID 0x0
41 OFPAT_STRIP_VLAN
42 OFPAT_SET_DL_SRC
43 OFPAT_SET_DL_DST
44 OFPAT_SET_NW_SRC
Switch recalculates IP checksum and UDP/TCP checksum if necessary
45 OFPAT_SET_NW_DST
Switch recalculates IP checksum and UDP/TCP checksum if necessary
46 OFPAT_SET_TP_SRC
Switch recalculates UDP/TCP checksum
47 OFPAT_SET_TP_DST
Switch recalculates UDP/TCP checksum
48 OFPAT_VENDOR
49 When action field doesn't exist, Switch drops the matched packets ("drop" action).
50 When multiple actions exist, Switch performs all of them. The order is not defined in the spec.
51 Using multiple actions Switch can send packet out to multiple/all ports.
When command is OFPFC_DELETE
52 Switch deletes the flow of matched entry.
53 If the entry doesn't exist, Switch doesn't do anything (it doesn't even send any error reports).
54 If out_port is other than OFPP_NONE, Switch erases the entry only if output port is also matched.
When command is OFPFC_DELETE_STRICT
55 Switch deletes the flow when both entry and priority are matched.
56 If the entry doesn't exist, Switch doesn't do anything (it doesn't even send any error reports).
57 If out_port is other than OFPP_NONE, Switch erases the entry only if output port is also matched.
8 flow_expiration OFPT_FLOW_EXPIRED ASYNC
1
Switch initiates OFPT_FLOW_EXPIRED message if OFPT_SET_CONFIG-OFPC_SEND_FLOW_EXP is set
2 Switch doesn't initiate OFPT_FLOW_EXPIRED message if OFPT_SET_CONFIG-SEND_FLOW_EXP is not set
3 Switch sends the following information in OFPT_FLOW_EXPIRED.
entry
priority
reason(HARD TIMEOUT or IDLE TIMEOUT)
duration
packet_cnt
byte_cnt
4
The reason is either HARD_TIMEOUT or IDLE_TIMEOUT, depending on OFPT_FLOW_MOD and expiring situation.
5
If HARD_TIMEOUT is set, the flow must be expired after the specified time, even if Switch keeps receiving the matched packets.
9 Error OFPT_ERROR SYM
1
When exchanging OFPT_HELLO, if Switch and Controller don't have OpenFlow version compatibility, the receiver of OFPT_HELLO sends error as follows:
OFPET_HELLO_FAILED
OFPHFC_INCOMPATIBLE
On Controller/Switch message, if header or vendor information has problem and request is not understood, send error as follows:
OFPET_BAD_REQUEST
2 OFPBRC_BAD_VERSION version not supported
3 OFPBRC_BAD_TYPE type not supported
4 OFPBRC_BAD_STAT ofp_stats_request type not supported
5 OFPBRC_BAD_VENDOR ofp_vendor, ofp_stats_request, ofp_stats_reply: vendor not supported
6 OFPBRC_BAD_SUBTYPE vendor subtype not supported
Error about action description
7
When action description (of what messages???) is something wrong, Switch sends following "type" and "code" and at least the first 64 bytes of the failed request
OFPET_BAD_ACTION
8 OFPBAC_BAD_TYPE unknown action type
9 OFPBAC_BAD_LEN length problem
10 OFPBAC_BAD_VENDOR unknown vendor id
11 OFPBAC_BAD_VENDOR_TYPE unknown action type for vendor id
12 OFPBAC_BAD_OUT_PORT problem validating output action
13 OFPBAC_BAD_ARGUMENT bad action argument
When OFPT_FLOW_MOD performed, if table in Switch is full, Switch sends an error message as follows:
OFPET_FLOW_MOD_FAILED
14 OFPFMFC_ALL_TABLES_FULL
10 Others VENDOR EXTENSION OFPT_VENDOR SYM Vendor specific, but when something is wrong with the message, Switch sends back an error message to Controller (See Error section).
11 Unexpected behavior Connection Loss 1 Switch doesn't do anything and it lets the flows expire.
(...But if hard timeout is not set, they may not expire at all...)
Notice when flow is
expired
Assert Error message
when necessary

12 Controller connection Protocol
1
Switch can connect Controller either via plain TCP or over SSL.
2 Switch can connect to any fixed IP address and TCP port number (even though it assumes tcp:6633 by default)
13 Other features 802.1d STP support 1 If Switch supports STP, Switch tells so to Controller via OFPC_STP bit on OFPT_FEATURES_REPLY during its initializing phase.
2 STP-supporting Switch must process 802.1D packets before flow lookup.
3 Switch updates the "struct ofp_phy_port" according to the decision made with STP process
4 When outport is OFP_FLOOD, Switch restricts the output ports based on the state on ofp_phy_port.
5 When outport is OFP_ALL, Switch ignores STP port state when forwarding.

regression test coverage
test_hello 0,5
no
test_hello
no
no (see Error section)
no 0
no
no 0
no

no
no
no (only "FLOW_EXP enable" is tested on all the datapath tests) 0,4285714286
test_switch_config
test_miss_send_length
no
test_Switch_config
test_Switch_config
no
no
test_flow_stats, test_port_stats 0,5
partially.
no
test_flow_stats
no
no
test_port_stats
no
no
no
test_flow_stats
test_flow_stats but only 1 pattern.
no
test_flow_stats but not verified.
no
no
no
no

no
no
test_port_stats
test_port_stats but not verified or displayed
test_port_stats but not verified or displayed
no
no
no 0
no
no
test_packet_in 0,75
test_XXX_Controller
no (buffer id is not checked)
test_packet_in
test_packet_out
test_packet_out
no
many tests... 0,5
no
test_miss_send_length (buffer is not checked, and proceeding action
(packet_out) is not been made.)

no
no
no
no
no
no
no
test_forward_exact_port/all/Controller
test_forward_exact_icmp_port/all/Controller/fool
no
many tests...
test_llc (but not performed as auto-run test)
no
test_forward_wildcard_port/all/Controller
no
no
no
test_forward_wildcard_port/all/Controller, but netmask is not tested
test_forward_wildcard_port/all/Controller, but netmask is not tested
test_forward_any_port (wildcard=0x3ff --> must be corrected to fff)
no
no
no
no
no
no
no
no
test_forward_exact_all, test_forward_wildcard_all,
test_forward_exact_icmp_all, test_forward_wildcard_icmp_all,
test_forward_exact_Controller, test_forward_wildcard_Controller,
test_forward_exact_icmp_Controller,
test_forward_wildcard_icmp_Controller
test_forward_exact_port, test_forward_wildcard_port,
test_forward_exact_icmp_port, test_forward_wildcard_icmp_port

no
no
no
test_forward_modify_action
no
test_drop_exact
no
test_delete
no
no
test_delete_strict
no
no
test_flow_expired, test_forward_after_expiration, and many other tests 0,4
no
yes and checked
no
no
no 0
no
no
no
no
no
no
no
no
no
no
no
no
no
no 0

no 0
no
no 0
no
no
no
no
TOTAL COVERAGE 0,256547619

Carlos arteche gonzalez

Más contenido relacionado

Similar a Carlos arteche gonzalez (20)

Último (20)

Carlos arteche gonzalez