Libro de Simulación-Redes Definida Por Software Con Mininet

Capítulo 1 REDES DEFINIDAS POR SOFTWARE: Marco teórico
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

Libro de clase desarrollado durante el desarrollo del curso “Arquitectura de Redes
Virtuales (SDN-NFV)” con los aportes de los alumnos del semestre 2022-I
Lima, 5 de setiembre 2022

INDICE
Capítulo 1 Redes Definidas por Software: Marco teórico

1.1 Introducción
1.2 Arquitectura de la Red Definida por Software
1.3 Interfaces
1.4 Conmutador OPENFLOW
1.5 Sistema operativo de la Red Definida por Software
Bibliografía
Capítulo 2 Máquinas virtuales con Ubuntu y Mininet

2.1 Introducción
2.2 Descarga de la imagen de Ubuntu
2.3 Ubuntu 20.04.4 en VirtualBox
2.3.1 Máquina Virtual con Ubuntu
2.3.2 Selección del ISO del Ubuntu
2.3.3 Instalación del Ubuntu 20.04.4 en VirtualBox
2.3.4 Ingreso al Ubuntu 20.04.4 en VirtualBox
2.3.5 Modo NAT del Ubuntu 20.04.4 en VirtualBox por defecto
2.3.6 Instalación de ifconfig en Ubuntu 20.04.4
2.4 Instalación del Mininet
2.4.1 Comandos Básicos
2.4.2 Repositorios Git
2.4.3 Instalación del Mininet
2.5 Simulador Mininet
2.5.1 Introducción al simulador Mininet
2.5.2 Topologías definidas en el simulador Mininet
2.6 Miniedit
2.6.1 Activación del MiniEdit
2.6.2 Simulación con MiniEdit
2.6.3 Wireshark con MiniEdit
2.6.4 Almacenamiento de la red simulada
2.7 Clonación de Máquina Virtual
Bibliografía
Capítulo 3 Controlador Ryu

3.1 Controlador Ryu
3.2 instalación del Controlador Ryu
3.2.1 Instalación del Controlador Ryu en Ubuntu
3.2.2 Inicio del controlador Ryu en Ubuntu
3.2.3 Controlador Ryu en MiniEdit
3.2.4 Controlador Ryu y Wireshark
3.3 Instalación de la aplicación flowmanager de Ryu
3.4 Redes Dual Stack SDN con Ryu: IPv4/IPv6
Bibliografía
Capítulo 4 Controlador OpenDayLight

4.1 Controlador OpenDayLight
4.2 Actualización del Sistema Operativo
4.3 Instalación de Java JRE versión 8
4.4 Establecer la variable JAVA_HOME en Java versión 8
4.5 Instalación de Java JRE version 11 y la variable JAVA_HOME
4.6 Descarga del archivo tar.gz opendaylight
4.7 Instalación de OpenDayLight
4.8 Inicio de OpenDayLight

4.9 Simulación de una red SDN con OpenDayLight
4.10 Observaciones complementarias
Bibliografía
Capítulo 5 Controlador ONOS

5.1 Controlador ONOS
5.2 Instalación del controlador ONOS
5.2.1 Actualización del Ubuntu
5.2.2 Instalación de Java JDK
5.2.3 Instalación de Maven
5.2.4 Instalación de Apache Karaf 3.0.5
5.2.5 Instalación del repositorio git-core
5.2.6 Descarga del controlador ONOS
5.2.7 Aplicación gráfica del controlador ONOS
5.2.8 Instalación de las aplicaciones en ONOS
5.3 Simulación de una red SDN con el controlador ONOS
5.3.1 Red con MiniEdit
5.3.2 Visualización de la red desde la interfaz gráfica del controlador
ONOS
5.4 Acceso al ONOS con CLI
5.5 Resumen de configuración del controlador ONOS
CAPÍTULO 1
REDES DEFINIDAS
POR SOFTWARE:
Marco teórico
1.1 INTRODUCCIÓN
Entre las características de la actual Internet está que sus dispositivos de
interconexión, routers y conmutadores, tienen ambos planos de control y datos en
el mismo equipo, generando un control descentralizado, donde los datos son
enrutados principalmente considerando el contenido de su tabla de enrutamiento,
basado en el prefijo de red del destino, sin considerar aspectos de congestión; esto
hace que sea poco flexible cuando se desea modificar parámetro en el más breve
tiempo. Por otro lado, en Bagaa et al (2020) se indica que con la llegada de 5G se
van a generar nuevos servicios con requisitos estrictos; donde la red 5G consta de
tres partes: red de acceso de radio (Radio Access Network, RAN), red central y red
de transporte. Es esta última red la que conecta la RAN (nuevas tecnologías de
radio, MIMO, etc.) con la red central (basada en software y haciendo uso de la nube),
facilitando nuevos servicios y aplicaciones con valor agregado ubicados en
diferentes servidores. Es aquí donde la red central debe ofrecer servicios
optimizando las rutas entre extremos (End-to-End, E2E), reflejando menores
retardos y uso adecuado de cada enlace. Una manera de ofrecer QoS en esta red
es sobre provisionando sus recursos considerando las demandas máximas;
relacionando estrictamente los recursos en los enlaces y nodos de la red de
transporte subyacente. Esta solución de asignación excesiva de recursos se vuelve
ineficiente cuando surgen nuevas aplicaciones y servicios exigiendo grandes
demandas. Esto genera que la red móvil no pueda adquirir o modificar los recursos
del medio de transporte asignado, debido a que la ruta definida no considera la
movilidad del usuario. Una alternativa es la identificación de rutas con baja
congestión para mejorar la QoS de la red de transporte.
Para obtener una red flexible, un nuevo modelo de red está casi madura, consiste
en la separación de los planos de control y datos, originando un control centralizado.
El control se ubica en servidor o servidores externos denominado controlador
logrando que SDN sea flexible debido principalmente que el controlador o
controladores tienen una visión completa de su red. Facilitando la implementación
de diferentes tipos de políticas de enrutamiento, seguridad, monitoreo del tráfico de
información en tiempo real y gestión de SDN con solo programar al controlador. En
este nuevo modelo es necesario un protocolo que permita al controlador y a los
conmutadores intercambiar mensaje y datos; este protocolo es el OpenFlow.
1.2 ARQUITECTURA DE LA RED DEFINIDA POR SOFTWARE
La consolidación de una red con control centralizado se inicia en el 2007, en la
Universidad de Stanford. En el artículo de Casado, M. et al (2007) se propone una
nueva red denominada Ethane basado en dos principios: El primero, control
centralizado que gestiona la entrada y el envío de los flujos que ingresan en los
conmutadores. Es decir, el controlador central contiene las políticas de red global
para determinar el destino de los flujos, previa admisión de ellos. Para ello el
controlador conoce la topología de red global y realiza el cálculo de ruta para los
flujos permitidos. El segundo, los conmutadores son simples sin inteligencia basada
en una tabla de flujo y con un canal seguro de comunicación con el controlador
centralizado. Cuando un flujo llega al conmutador y no existe información en la tabla
de flujos para su conmutación, el conmutador envía el flujo al controlador para su
análisis y toma de decisión; para posteriormente informar a los conmutadores de las
acciones a tomar. En el artículo de Casado, M. et al (2019) se analiza la evolución
de Ethane a SDN, siendo SDN una red adecuada para la innovación; para ello se
debe cumplir con definir interfaces abiertas e impulsando nuevos algoritmos
implementados en el controlador de SDN.
En el documento ONF (2016) se actualiza SDN y se considera como entidad central
al controlador SDN, modelando a esta entidad como una relación cliente-servidor.
El controlador SDN como servidor puede ofrecer servicios a cualquier número de
clientes, mientras un cliente puede solicitar servicios. En SDN se plantea tres
principios y la definición de interfaces abiertas para SDN. El primer principio, el
desacoplo de reenvío y procesamiento del tráfico de control, permite implementar de
manera independiente los procesos de reenvío, gestión del tráfico de información y
los procesos de control. Este desacoplo es una condición para implementar el control
centralizado y facilitar la optimización separada de la tecnología de la plataforma y
el desarrollo del software de control. Este principio genera una entidad llamada
controlador SDN que tiene la responsabilidad de control y gestión de los recursos
ubicados en el plano de datos. El administrador de la red tiene acceso al control de
la gestión de un conjunto real y/o virtual de recursos y servicios creados y expuestos
por el controlador SDN, sin que el administrador tenga la necesidad de conocer la
tecnología utilizada en su implementación. El segundo principio, control lógicamente
centralizado, faculta la implementación del control de manera distribuida, pero
comportándose como una sola entidad; es decir, dentro de la arquitectura SDN los
controladores SDN pueden asociarse con otros controladores SDN. Este principio
de control centralizado permite, a través del controlador SDN, tener una perspectiva
global de la red y que trae como consecuencia que los recursos se pueden usar de
manera más eficiente. Un controlador SDN puede orquestar recursos que abarcan
un conjunto de entidades subordinadas, y de ese modo ofrecer mejores
abstracciones a sus clientes. El tercer principio, la programabilidad de los servicios
de red, se basa sobre la premisa que las aplicaciones están habilitadas para
especificar requisitos y solicitar cambios en sus servicios de red. Es decir, permite
que un cliente intercambie información con un controlador SDN antes del
establecimiento de un servicio; o cuando el servicio está ofreciéndose el cliente

puede solicitar cambios según sus necesidades. Es este último principio en que se
basa el presente trabajo de investigación para implementar el balanceo de carga
dinámico.
El principio de la programabilidad obliga la existencia de interfaces públicas y
abiertas para fomentar la competencia en su implementación y proponer estándares
abiertos en lugar de propietarios. En esencia, estas interfaces o APIs permiten que
un “sistema” envíe una solicitud o responda a las consultas.
En Hamdan, M. et al (2020), Schaller, S. et al (2017), Benzekki et al (2017) y Kreu
et al (2015) analizan SDN como una arquitectura organizada en tres capas: capa de
aplicación, capa de control y capa de infraestructura o datos; además de sus cuatro
interfaces: interfaz hacia el norte (northbound), interfaz hacia el sur (southbound),
interfaz hacia el este (eastbound) e interfaz hacia el oeste (westbound); cómo se
observa en la figura 1.1. La capa de aplicación contiene aplicaciones y servicios SDN
diseñados para cumplir los requisitos del usuario; es aquí donde se define las reglas
y se ofrecen servicios como firewall, control de acceso, calidad de servicio,
enrutamiento, monitoreo del tráfico de información en tiempo real y balanceo de
carga entre otros. Tiene como responsabilidad abstraer la administración del control
de la red; para ello hace uso de la API hacia el norte (northbound). La capa de control
ofrece una abstracción de la topología de la red. Tiene como elemento al controlador
y es el responsable de establecer las tablas de flujo y las políticas del manejo de
datos. La comunicación con la capa inferior para recopilar información de la red lo
realiza a través de la API hacia el sur (southbound), siendo el OpenFlow el protocolo
ampliamente aceptado en la actualidad en esta interfaz. La capa de infraestructura
o datos, suministra los dispositivos de interconexión tales como conmutadores
físicos/virtuales, routers y access point; contiene las tablas de flujo y es el
responsable del manejo de los datos: reenvío, fragmentación y reensamblado.
Figura 1.1 Capas e interfaces de la arquitectura SDN [Elaboración propia]

La Unión Internacional de Telecomunicaciones (ITU) en la recomendación ITU-

T.G.7702 (2018) considera a SDN como una tecnología a ser utilizada en la red de
transporte, donde los gestores de aplicaciones y servicios solicitarán y
proporcionarán conexiones extremo-a-extremo con acuerdos de niveles de servicios
(Service Level Agreements-SLA) garantizados como ancho de banda, retardo,
disponibilidad, error y rendimiento. En resumen, en Khorsandroo et al. (2021) se
indica que los beneficios de SDN son: programabilidad y automatización, gestión
reduciendo los costes operativos simplificando la tarea de gestión y la virtualización
de la red.
1.3 INTERFACES
Interfaz southbound.- La Interfaz de Programación de Aplicaciones (API)
southbound o interfaz hacia el sur permite la comunicación entre controlador SDN y
conmutadores que forman la SDN. A través de esta API southbound, el controlador
SDN puede crear, modificar y borrar tablas de flujo ubicados en cada conmutador
de manera dinámica en tiempo real, en función de las demandas o necesidades de
las aplicaciones. Por otro lado, los conmutadores o dispositivos de reenvío pueden
enviar al controlador SDN flujos de datos para que este controlador decida acciones
a realizar en el Conmutador. La ONF define al protocolo OpenFlow como interfaz
southbound de código abierto; aunque algunos fabricantes de dispositivos de
comunicaciones SDN definen su propio API southbound, por ejemplo, CISCO define
su API southbound denominado OpFlex. En cualquiera de los casos, la Interfaz
southbound permite la abstracción de los conmutadores que forman SDN.
Interfaz northbound.- La Interfaz de Programación de Aplicaciones (API)

northbound o interfaz hacia el norte permite la comunicación entre los servicios y
aplicaciones ubicados en la capa de aplicación con el controlador SDN; son las APIs
más críticas de la arquitectura SDN debido a que a través de esta interfaz se
controlará el rendimiento de la capa de datos, la seguridad, el monitoreo de SDN,
balanceo de carga, entre otros; siendo esta interfaz el que permite la
programabilidad de SDN. El fin de la Interfaz northbound es abstraer u ocultar el
funcionamiento interno de la SDN, de modo que los desarrolladores de aplicaciones
puedan conectarse a la red y hacer cambios para adaptar las necesidades de las
aplicaciones, sin tener que entender exactamente la composición interna de la red1.
Es ésta Interfaz que está permitiendo crear un conjunto de aplicaciones para
gestionar las diferentes necesidades en SDN: balanceo de carga, calidad de
servicios, firewall, seguridad, monitoreo de tráfico de información en tiempo real,
1
https://www.sdxcentral.com/sdn/definitions/north-bound-interfaces-api/
entre otras; impulsando la innovación o creatividad de los desarrolladores de

aplicaciones.
La Interfaz northbound debe promover la portabilidad de las aplicaciones; es decir,

la aplicación debe ser ejecutado en diferentes plataformas o controladores, con
menos recursos y en menor tiempo, de allí la necesidad de la abstracción. Además,
debe facilitar la interoperabilidad; definiendo interfaces y procedimientos totalmente
conocidos para que puedan comunicarse con diferentes controladores SDN
existentes o futuros.
En la figura 1.2 se muestra la interrelación de la capa de control con la capa de

aplicación a través de la interfaz northbound y de la capa de control con la capa de
datos o infraestructura a través de la interfaz southbound.
Figura 1.2 Interfaces en SDN [Elaboración propia]
1.4 CONMUTADOR OPENFLOW

SDN es una arquitectura de red basada en flujo y un flujo es un grupo de paquetes
IP que se generan en uno o más nodos IP y se dirigen a uno o más nodos IP de
destino. Los datos que pertenecen a un flujo debe cumplir con un conjunto de
características comunes; por ejemplo, que tengan una dirección MAC y/o dirección
IP particular, o que todos los datos tengan el mismo valor de ID VLAN según IEEE
802.1q; en general los datos que forman un flujo deben corresponder con los valores
de campos definidos en los protocolos de capa 2, 3 y 4. Por ejemplo: una dirección
MAC de origen en particular, una dirección IP específico, el mismo valor de campo
protocolo de IP y un determinado valor del puerto de origen de la capa de transporte.
Los conmutadores en SDN, manejan flujos y son los responsables del re-envío de
flujos desde un puerto de este dispositivo a otro puerto. En el artículo de McKeown,
N. et al (2008) se fundamenta el modelo de un Conmutador constituido por tres
elementos. Una tabla de flujo, donde se define una acción a realizar por cada flujo
de entrada y ordena al Conmutador como procesar al flujo; por ejemplo, un flujo que
ingresa por un puerto del Conmutador y cumple ciertas condiciones son reenviados
a uno de los puertos de salida de este conmutador, en caso contrario son eliminados
o enviados a controlador SDN. Un canal seguro, que conecta el Conmutador con
el controlador SDN por donde circulan comandos y paquetes de los flujos entre
ambos dispositivos. El protocolo OpenFlow que provee un estándar abierto para la
comunicación entre el Conmutador y el controlador SDN, es través de este protocolo
que las entradas en la Tabla de Flujo pueden ser definidas externamente. Este
protocolo permite la programación del Conmutador externamente, materializando el
concepto de separación del plano de control del plano de datos.
En la figura 1.3 se muestra la estructura interna del Conmutador. Todo Conmutador

puede disponer de uno o más canales seguros OpenFlow para comunicarse con el
controlador, intercambiando por este canal paquetes de datos y mensajes. La
especificación de SDN considera uno o más controladores, pero trabajando como
uno sólo. De manera sencilla el Conmutador recibe un dato de entrada por uno de
sus puertos (el puerto 2) y debe enviarlo a uno de sus puertos de salida (el puerto
n) definiendo una trayectoria de datos.
Dentro del Conmutador existe un grupo de Tablas de Flujo interconectados en una

arquitectura pipeline; es decir, el análisis de un flujo se divide en cada Tabla de Flujo
y la salida de una Tabla de Flujo es la entrada de la siguiente Tabla de Flujo; el
procesamiento puede ser solamente hacia adelante y nunca de retorno. Estas tablas
están numeradas, empezando con la Tabla 0, como se observa en la figura 1.4.
Figura 1.3 Modelo de un Conmutador [Elaboración propia]
Cuando unos datos ingresan al Conmutador, se analiza el cumplimiento de campos

definidos previamente en la Tabla de Flujo (flow entry, elementos en una Tabla de
Flujo usado para identificar el flujo de datos), denominada Función Packet-matching;
a continuación, se realiza una acción con estos paquetes. El bloque Acción
fundamentalmente define un grupo de acciones como: enviar del paquete de datos
al puerto de salida del Conmutador seleccionado, eliminar datos, pasar los datos a
uno de los controladores SDN usando el mensaje del protocolo OpenFlow
denominado PACKET_IN o envía el dato a la Tabla de Medición.
Figura 1.4 Arquitectura pipeline de las tablas de flujo [Elaboración propia, adaptada de ONF (2015)]
En la especificación del protocolo OpenFlow detallado en ONF (2015) se explica

cuando el controlador SDN envía un paquete de datos al Conmutador usando el
mensaje del protocolo OpenFlow denominado PACKET_OUT. Al llegar un paquete
de datos al Conmutador, se puede enviar directamente el paquete de datos al puerto
de salida del conmutador o el controlador especifica que se vuelva a analizar el
proceso de envío en la etapa de la Función Packet-matching con las Tablas de Flujo.
Los paquetes de datos pueden ser enviados a un puerto físico o puerto virtual; este
último para realizar túneles. Una tabla de flujo permite enviar un flujo a una Tabla de
Grupo para que se inicie un conjunto de acciones sobre este flujo; esta tabla permite
realizar, por ejemplo, agregación de enlaces o envío multicast o broadcast. Es
importante recalcar lo que en esta especificación se indica, un Conmutador puede
trabajar en dos formas distintas; como Conmutador puro o como Conmutador
híbrido. En la primera forma, el proceso de re-envío se realiza de acuerdo al
contenido de las Tablas de Flujo y en la segunda forma el proceso de re-envío puede
ser realizado en base a las Tablas de Flujo o la conmutación de acuerdo a criterios
clásicos de los conmutadores Ethernet o routers IP.
En la figura 1.5 se muestra de manera resumida el funcionamiento de un conmutador

SDN.
Figura 1.5 funcionamiento de un conmutador SDN [Elaboración propia]
1.5 SISTEMA OPERATIVO DE LA RED DEFINIDAS POR SOFTWARE

En las redes tradicionales, según Kreutz et al (2015), la administración y
configuración de los dispositivos de interconexión se han realizado y se viene
realizando hasta ahora utilizando conjuntos de instrucciones específicos del
dispositivo (CLI, Command Line Interface), con sistema operativo en cada equipo
(descentralizados) y propietarios; sin poder acceder al código (por ejemplo, Cisco
IOS, Juniper JunOS y Huawei VRP-Versatil Routing Platform). Un problema
presente en los desarrolladores de protocolos de enrutamiento, balanceo de carga
e ingeniería de tráfico radica en que sus algoritmos al ser distribuidos son complejos
para minimizar la congestión en este tipo de redes legadas.
En SDN el sistema operativo de la red (NOS, Network Operating Systems), se ubica
en el controlador y conteniendo la inteligencia de la red de manera centralizada. Este
software se encarga de las tareas de gestión de datos de la red, servicios a las
aplicaciones, autenticación y gestión de API, entre otras acciones; facilitando su
desarrollo y ocultando de esta manera la heterogeneidad de la arquitectura de la red
y los protocolos de red que lo forman. NOS viene a ser el middleware de SDN;
separando las aplicaciones de gestión de la red de los protocolos inherentes de toda
red y de la arquitectura subyacentes; con el objetivo de ofrecer a los desarrolladores
de las aplicaciones de gestión de la red una comunicación con los datos y los
usuarios que hacen uso de las aplicaciones finales. Sintetizando, un NOS en SDN
es un elemento crítico e indispensable porque contiene toda la lógica del
funcionamiento de la red que ofrecerá políticas definidas por el administrador de la
red de manera simple.
NOS en SDN pueden ser desarrollado en software libre o propietario. ONF impulsa
una arquitectura SDN basada en software libre. En la actualidad existen varios NOS
en software libre, siendo los más populares, según Mamushiane et al (2018) y Arun
et al (2019): Ryu, OpenDayLight, Floodlight y ONOS.
Un análisis de los más populares de los controladores se da en Mamushiane et al
(2018), este consiste en medir la latencia y el rendimiento con diversas cargas de
trabajo. La evaluación se realizó utilizando el programa Cbench, que es una
herramienta de medición del rendimiento de controladores compatibles con
OpenFlow; para ello genera eventos de entrada PACKET_IN para nuevos flujos
emulando un grupo de conmutadores que se conectan al controlador y contando el
número de respuestas PACKET_OUT recibidos por segundo, así como su latencia.
En la figura 1.6 se muestra un escenario de prueba para los controladores.
Figura 1.6 Escenario para medir el rendimiento de controladores [Mamushiane et al (2018)]
Uno de los resultados de Mamushiane et al (2018) es la evaluación del rendimiento

de los cuatro (04) controladores SDN (Ryu, OpenDayLight, Floodlight y ONOS),
como se muestra en la figura 1.7. Floodlight y OpenDayLight se ven afectados
drásticamente por un aumento en el número de conmutadores activos que exige una
alta potencia de procesamiento. El rendimiento de procesamiento de Ryu es el más
pobre y permanece constante independientemente del número de conmutadores

emulados. ONOS exhibe el mejor rendimiento debido a que es un controlador
inherente para redes de gran escala.
En Arun et al (2019) se analiza el rendimiento de cuatro (04) controladores SDN:
Ryu, OpenDayLight, Floodlight y ONOS considerando dos parámetros de QoS: el
retardo promedio y el rendimiento; para ello considera tres (03) topologías de red
diferentes para varios números de conexiones entre 10 y 50, estas topologías son:
lineal, árbol y malla. La metodología utilizada fue la generación de solicitudes
utilizando el comando ping y la generación de tráfico con la herramienta IPerf3
(Herramienta para medir ancho de banda, pérdida de paquetes, jitter, retardo, en
protocolos TCP, UDP, con IPv4 e IPv6). IPerf3 fue desarrollado por ESnet/Lawrence
Berkeley National Laboratory). Una de las conclusiones es que el controlador
Floodlight ofrece una demora inferior en comparación con los otros controladores en
todas las topologías de red y se recomienda analizar otros parámetros de QoS y ver
aspecto de seguridad.
Figura 1.7 Número promedio de respuestas por segundo con un número variable de
conmutadores, MAC = 1000 [Mamushiane et al (2018), figura 2]
Para ambos estudios es indispensable introducir nuevos escenarios de análisis que

consideren aspectos de balanceo de carga, para cuantificar el rendimiento de los
controladores en SDN más utilizados. En la Tabla 1.1 se da un resumen de las
principales características de estos cuatro controladores.
Tabla 1.1 Comparación entre los principales controladores SDN [Adaptado

Mamushiane et al (2018)]
BIBLIOGRAFÍA
Arun, A., Neethu, S., Ravish, A. (2019). Performance Analysis of Various SDN Controllers
In
Mininet Emulator. 2019 4th International Conference on Recent Trends on
Electronics, Information, Communication & Technology (RTEICT-2019), MAY 17th &
18th 2019. DOI: 10.1109/RTEICT46194.2019.9016693.
Bagaa, M., Dutra, D., Taleb, T., Samdanis, K. (2020). On SDN-driven Network
Optimization and QoS aware Routing using Multiple Paths. IEEE Transactions on
Wireless Communications (Volume: 19, Issue: 7, July 2020).
DOI: 10.1109/TWC.2020.2986408
Benzekki, K., Fergougui, A., Elalaoui, A. E., (2017). Software-deﬁned networking (SDN): a
survey. DOI: 10.1002/sec.1737
Hamdan, M., Hassan, E., Abdelaziz, A., Elhigazi, A., Mohammed, B., Khan, S., Vasilakos,
A., Marsono, M. (2020). A Comprehensive Survey of Load Balancing Techniques in
Software-Defined Network. Journal of Network and Computer Applications, DOI:
https://doi.org/10.1016/j.jnca.2020.102856
ITU-T.G.7702 (2018). Architecture for SDN control of transport networks.

https://www.itu.int/itu-t/recommendations/rec.aspx?rec=13540
Khorsandroo, S., Gallego, A., Saman, A., Arco, JM., Doriguzzi-Corin, D. (2021). Hybrid
SDN evolution: A comprehensive survey of state-of.art. Computer Networks 192
(2021) 107981. DOI: https://doi.org/10.1016/j.comnet.2021.107981
Kreutz, D., Ramos, F. M., Veríssimo, P.E., Rothenberg, C. E., Azodolmolky, S., Steve
Uhlig, U. (2015). Software-Defined Networking: A Comprehensive Survey.
Proceedings of the IEEE. (Vol. 103). DOI: 10.1109/JPROC.2014.2371999
Mamushiane, L., Lyko, A., Dlamini, S. (2018). A Comparative Evaluation of the

Performance of Popular SDN Controllers. 10th Wireless Days Conference (WD).
DOI: 10.1109/WD.2018.8361694.
McKeown, N., Anderson, T., Balakrishnan, H. (2008). OpenFlow: Enabling Innovation in

Campus Networks. ACM SIGCOMM Computer Communication Review
ONF-2015-Open Networking Foundation. OpenFlow Switch Specification-v1.5.1.

https://www.opennetworking.org/
Schaller, S., Hood, D., (2017). Software Defined Networking

Architecture Standardization.
Capítulo 2. MÁQUINAS VIRTUALES CON UBUNTU Y MININET
CAPÍTULO 2
MÁQUINAS VIRTUALES
CON UBUNTU Y MININET
2.1 INTRODUCCIÓN
El sistema operativo de software libre Ubuntu, de código libre, se ha convertido en
el sistema operativo indispensable para estudiar el funcionamiento de redes de
datos emergentes como es el caso de SDN, SD-IoT, cloud, entre otros. A la par de
la evolución de la tecnología en telecomunicaciones, los sistemas operativos son
más confiables y ha contribuido a su adopción casi inmediata por parte de los
usuarios finales.
Ubuntu es un sistema operativo (SO) Linux basado en Debian de código abierto
gratuito, con licencia GNU-General Public License. El sistema operativo Ubuntu
tiene varias versiones, como la versión de escritorio, la versión del servidor y la
versión móvil. La versión última de Ubuntu de escritorio al momento de escribir este
libro es el Ubuntu 22.04. Aún así, se instala la Ubuntu 20.04.4 LTS para ser utilizado
con el simulador Mininet para las Redes Definidas por Software-SDN; para luego
ser utilizado, como máquinas virtuales, desde el GNS3; de esta manera se dispondrá
GNS3 con máquinas virtuales conteniendo el sistema operativo de SDN Ryu,
OpenDayLight y ONOS.
2.2 DESCARGA DE LA IMAGEN ISO DE UBUNTU
Para obtener el Ubuntu Desktop versión 20.04.4 LTS se debe ingresar a la dirección
Web: https://releases.ubuntu.com/focal/; como se ilustra en la figura 2.1 y acceder a
la opción 64-bit PC (AMD64) desktop image ; obteniendo el
archivo ejecutable ubuntu-20.04.4-desktop-amd64.
Figura 2.1 Descarga del Ubuntu 20.04.4

Almacene la imagen ISO en su escritorio de trabajo, para la instalación posterior en

el VirtualBox.
La imagen de la versión Ubuntu de escritorio permite probar el sistema operativo

Linux sin cambiar la computadora de trabajo; esto permite instalar diversas
herramientas de simulación, como el Mininet para SDN. El requisito mínimo de
memoria RAM para instalar esta imagen es de 1024MiB (1024 MebiByte). 1024 MiB
equivale a 1 GiB (GibiByte); 1 MiB es igual a 220 bytes = 1 048 576 bytes.
La mayoría de las computadoras personales tienen como microprocesador basado
en la arquitectura AMD64, que fue desarrollado por Advanced Micro Devices
(AMD), que es de 64 bits. Dos grandes características ofrecen la arquitectura
AMD64: los registros internos del microprocesador son de 64 bits y la capacidad de
utilizar memorias RAM es alrededor de 16 Exabytes o 16 millones de Terabytes (en
los microprocesadores de 32 bits solo puede acceder como máximo 4 GB de RAM).
Para conocer el tipo de arquitectura de su PC:
✓ Selecciones Windows
✓ En la nueva ventana seleccionar Sistema
✓ En la nueva ventana observe el Tipo de sistema:
Como se ilustra en la figura 2.2
Figura 2.2 Tipo de sistema de la PC con Windows

2.3 UBUNTU 20.04.4 EN VIRTUALBOX

2.3.1 Máquina virtual con Ubuntu
VirtualBox es un producto de virtualización x86 y AMD64 / Intel64 y está disponible
gratuitamente como software de código abierto bajo los términos de la GNU General
Public License (GPL) versión 2. Se ejecuta en hosts Windows, Linux, Macintosh y
Solaris.
Para instalar el Ubuntu 20.04.4 en VirtualBox se debe seleccionar Nueva desde

la interfaz gráfica del VirtualBox, como se ilustra en la figura 2.3
Figura 2.3 Nueva máquina virtual en VirtualBox
El proceso para configurar una nueva máquina virtual conteniendo el Ubuntu 20.04.4
en el VirtualBox se indica en las figuras 2.4a, b, c, d, e, f, g y h. Se debe ingresar el
nombre de la máquina virtual; en la figura 2.4b se colocó ubuntu-20.04.4; así mismo
seleccionar el directorio o carpeta donde se instalará el Ubuntu.
Es importante considerar el tamaño del disco duro virtual. Se recomienda 50GB para
instalar Ubuntu, el simulador SDN denominado Mininet, controlador de red Ryu,
OpenDayLight o ONOS, entre otras aplicaciones. En la figura 2.4g se instaló 50GB
de disco duro virtual.
(a) (b)
(c) (d)
(e) (f)
(g) (h)
Figura 2.4 Nueva máquina virtual conteniendo el Ubuntu 20.04.4 en el VirtualBox
2.3.2 Selección del ISO del Ubuntu

El siguiente paso es seleccionar el ISO del Ubuntu 20.04.4 en el VirtualBox, para
ello una vez seleccionado “Ubuntu-20.04.4” se debe acceder a la opción
“Configuración” desde la interfaz gráfica del VirtualBox, como se ilustra en la
figura 2.5.
Figura 2.5 Configurar el ISO del Ubuntu 20.04.4 en el VirtualBox

De la nueva ventana seleccionar “Almacenamiento” y la opción “Vacío”

(figura 2.6a). Luego en la opción Atributos, desde “Unidad óptica”
seleccionar el ícono y en la nueva ventana emergente elegir la
opción “Seleccionar un archivo de disco…” como se ilustra en la figura 2.6b. Se
debe ubicar el directorio que contiene el ISO del Ubuntu 20.04.4; una vez aceptado
se regresa a la interfaz gráfica del VirtualBox como se ilustra en las figuras 2.6c y
2.6d.
(a) (b)
(c) (d)
Figura 2.6 Selección de ISO del Ubuntu 20.04.4 en el VirtualBox
Observación:
Para continuar con una adecuada configuración se debe seleccionar el controlador gráfico de
pantalla VBoxSVGA, previa selección de la opción Configuración , como se ilustra en la figura
2.7. De esta manera se tendrá más control en las dimensiones de la pantalla en los siguientes
pasos de la configuración.
Figura 2.7
Si una vez finalizado con la configuración e ingresando al Ubuntu la pantalla se coloca en un color
fijo (por lo general negro) se debe regresar a la configuración del controlador gráfico en VMSVGA.
2.3.3 Instalación del Ubuntu 20.04.4 en VirtualBox

El paso final es instalar el Ubuntu en la máquina virtual creada en el VirtualBox. Para
ello, desde la interfaz gráfica del VirtualBox seleccionar la opción de “ubuntu-
20.04.4” y luego “Iniciar” Todo el proceso de instalación se ilustra en las
figuras 2.8a hasta 2.8l.
(a)
(b) (c)
(d) (e)
(f) (g)
(h) (i)
En esta parte de la instalación ingrese su nombre, el nombre de la máquina virtual,

nombre del usuario y elija una contraseña. En la figura 2.8j se observa estos
parámetros ingresados.
(j) (k)
El proceso de instalación del ubuntu 20.04.4 finaliza inicializando la máquina virtual;

como se ilustra en la figura 2.8l. En la nueva ventana pulsar ENTER.
(l)
Figura 2.8 Instalación del Ubuntu 20.04.4 en el VirtualBox
2.3.4 Ingreso al Ubuntu 20.04.4 en VirtualBox

Una vez inicializado la máquina virtual que contiene el Ubuntu, en la interfaz gráfica
de inicio pulse encima del nombre UNMSM (figura 2.9a) e ingrese la
contraseña configurada previamente, accediendo al entorno del ubuntu 20.04.4
(figura 2.9b). Al ingresar por primera vez, es posible que salga un anuncio para
actualizar el ubuntu 20.04.4; de ser el caso, siga con las indicaciones (figuras 2.9c y
2.9c). Se recomienda realizar posteriormente esta actualización.
(a) (b)
(c) (d)
Figura 2.9 Actualización del Ubuntu 20.04.4
Ahora queda activar el terminal del ubuntu; para realizar se debe seleccionar el ícono
, ubicado en la parte inferior izquierda, y en la nueva ventana ingresar la palabra
“terminal” , para activar un terminal del Ubuntu seleccionado el
ícono , inmediatamente surge el terminal como se ilustra en la figura 2.10a.
Finalmente, en este terminal ingrese el comando ping 8.8.8.8 para probar acceso a
Internet desde la máquina virtual que contiene Ubuntu 20.04.4 como se ilustra en la
figura 2.10b.
ping 8.8.8.8
(a) (b)
Figura 2.10 Acceso de Internet desde el Ubuntu 20.04.4 en el VirtualBox
2.3.5 Modo NAT del Ubuntu 20.04.4 en VirtualBox por defecto

Por defecto al instalar la máquina virtual con el Ubuntu 20.04.4 se configura en el
modo NAT. Para verificar esta configuración en “ubuntu-20.04.4” ,
seleccionar la opción “Configuración” y en la nueva ventana seleccionar “Red”
, como se ilustra en las figuras 2.11a y 2.11b
(a) (b)
Figura 2.11 Modo NAT de configuración por defecto del Ubuntu 20.04.4 en el VirtualBox
2.3.6 Instalación de ifconfig en Ubuntu 20.04.4

El comando ifconfig muestra todas las configuraciones de red en el sistema.
ifconfig no está instalado por defecto en el Ubuntu 20.04.4 como se ilustra en la
figura 2.12.
Figura 2.12 ifconfig en ubuntu 20.04.4 no está instalado
Para instalar ifconfig primero se debe actualizar los programas del Ubuntu con el
comando sudo apt update (figura 2.13) y luego instalar las herramientas que
permiten ver las configuraciones de red con el comando sudo apt install net-tools
(figura 2.14).
sudo apt update

sudo apt install net-tools
Figura 2.13 Actualización del ubuntu 20.04.4

Figura 2.14 Instalación de herramientas para ver las configuraciones de red
Nuevamente con el comando ifconfig se observará la interfaz (enp0s3) y su

dirección IP (10.0.0.5), como se ilustra en la figura 2.15.
Figura 2.15 Dirección IP de la interfaz de red
Observar que el comando ifconfig está siendo obsoleto y la tendencia es

reemplazar por el comando ip. Por otro lado, el comando which permite conocer la
ubicación de un archivo; por ejemplo, para conocer donde está ubicado ifconfig se
debe ingresar el comando which ifconfig, cómo se ilustra en la figura 2.16.
which ifconfig
Figura 2.16 Ubicación del comando ifconfig

2.4 INSTALACIÓN DEL MININET

Para el análisis e investigación de las redes definidas por software-SDN podemos
contar con un laboratorio físico conformado por varios conmutadores que soporten
OpenFlow y uno o más servidores donde esté instalado el sistema operativo de red
(Network Operating System-NOS) o contar con plataformas en software libre que
permita la simulación y/o emulación de una red SDN. Entre estas plataformas
podemos citar a Mininet (http://www.mininet.org) o al GNS3 adicionando máquinas
virtuales para que soporte SDN. Mininet es uno de los emuladores de redes más
utilizados en la investigación y la ingeniería; los principales artículos científico sobre
SDN basan sus análisis en simulaciones realizadas en Mininet.
Mininet es un emulador que se instala en Linux y permite el despliegue de SDN.
Para ello es necesario que el computador tenga previamente implementado software
de virtualización, por ejemplo, VirtualBox. Mininet utiliza el kernel de Linux y otros
recursos para emular a los conmutadores OpenFlow, el controlador conteniendo el
sistema operativo de red y los hosts. Existen plataformas que complementan la
simulación realizada en Mininet, que permite iniciar, visualizar y modificar flujos en
tiempo real; uno de ellos es MiniNAM (https://github.com/uccmisl/MiniNAM).
2.4.1 Comandos básicos
apt es un gestor de paquetes que proporciona órdenes para la búsqueda, gestión y
solicitud de información sobre los paquetes; proporciona la misma funcionabilidad
de apt-get, permitiendo opciones más apropiadas para un uso más interactivo. Entre
las órdenes más utilizadas están: apt update, apt upgrade, apt install [información
obtenida en man apt].
Update es utilizado para descargar información de paquetes de todas las fuentes
configuradas. Otros comandos operan sobre estos datos para realizar
actualizaciones de paquetes o buscar y mostrar detalles sobre todos los paquetes
disponibles para la instalación [información obtenida en man apt].
Upgrade se utiliza para instalar actualizaciones disponibles de todos los paquetes
actualmente instalados en el sistema desde las fuentes configuradas a través de
sources.list. Se instalarán nuevos paquetes si es necesario para satisfacer las
dependencias, pero los paquetes existentes nunca se eliminarán [información
obtenida en man apt].
Install realiza la instalación solicitada en uno o más paquetes especificados.
2.4.2 Repositorio Git

El repositorio Git o GitHub es un lugar virtual de almacenamiento de proyectos;
donde se guardan diversas versiones de un código para posteriormente ser
accedido desde la Internet por diversos desarrolladores ubicado en cualquier parte
del mundo. Los desarrolladores crean sus repositorios como remotos en
GitHub.com para permitir que cualquier otro desarrollador pueda clonar este
repositorio con el objetivo de crear una copia local en la computadora del
desarrollador para contribuir en su mejora o hacer uso del proyecto. Actualmente,
GitHub se ha convertido en uno de los repositorios de desarrollo más grande y
avanzada del mundo.
Se recomienda utilizar un comando update antes de instalar cualquier paquete para
que pueda obtener el paquete actualizado.
Para instalar Git se debe ingresar los siguientes comandos
sudo apt update

sudo apt install git
En las figuras 2.17 y 2.18 se muestra este proceso de instalación.
Figura 2.17
Como se observa en la figura 2.17 las direcciones web son repositorios que
contienen software; casi al final se muestra el mensaje “Leyendo lista de paquetes…
Hecho” para indicar que la computadora siguió adelante y leyó todo el software
disponible en los repositorios y los comparó con la versión presente y descubrió que
están actualizados.
Figura 2.18
Como se puede observar en la figura 2.19, desde el directorio de trabajo (en este
caso fiee) no existe algún directorio referido a Mininet.
ls
Figura 2.19
2.4.3 Instalación del Mininet

El primer paso para instalar de forma nativa Mininet desde la fuente es obtener el
código fuente clonando desde GitHub ingresando el comando sudo git clone
https://github.com/mininet/mininet, como se observa en la figura 2.20.
sudo git clone https://github.com/mininet/mininet

Figura 2.20
Una vez obtenida el código fuente del mininet, esta se ubica en el nuevo directorio
creado denominado mininet; como se muestra en la figura 2.21.
ls
Figura 2.21
Ahora se debe conocer las diversas versiones de Mininet; para ello se debe Ingresar
al directorio mininet y con el comando git tag observar las versiones disponibles;
como se ilustra en la figura 2.22.
cd mininet
git config --global --add safe.directory /home/unmsm/mininet
git tag
Figura 2.22
Se recomienda la versión 2.3.0d5 y su selección es realizado con el comando sudo

git checkout -b 2.3.0d5, como se observa en la figura 2.23. El uso de nuevas
versiones está sujeta a su verificación de compatibilidad de las nuevas versiones de
Ubuntu.
sudo git checkout -b 2.3.0d5
Figura 2.23
Para iniciar con la instalación de mininet, desde el directorio inicial fiee, instalar
mininet con el comando install.sh; en la figura 2.24 se indica el inicio de la
instalación.
cd ..
sudo mininet/util/install.sh
Figura 2.24
Al final del proceso de instalación del Mininet se tiene el mensaje: Enjoy Mininet!,
indicando que la instalación fue satisfactoria, como se observa en la figura 2.25.
Mininet contiene diversas topologías implementadas en SDN y permite probar
conectividad entre todos sus hosts con el comando pingall disponible desde Mininet.
Figura 2.25
Una de las topologías predeterminadas simple incluye un Controlador SDN (c0), un

conmutador SDN o OpenFlow (s1) y dos hosts (h1 y h2) conectados al conmutador
SDN o OpenFlow, como se muestra en la figura 2.26.
Figura 2.26
Para invocar a esta topología simple y probar conectividad desde el host h1 al host
h2 y desde el host h2 al host h1 se debe ingresar el comando sudo mn --test
pingall, como se ilustra en la figura 2.27.
sudo mn --test pingall
Figura 2.27
El mensaje “ ***Done completed in 5.487 seconds ” es el indicador de que Mininet

está instalado de manera satisfactoria (el tiempo en segundos puede variar).
2.5 SIMULADOR MININET
Mininet está construido en lenguaje Python y permite crear topologías
personalizadas, establecer parámetros en los elementos de la red y ejecutar
programas mediante CLI o un API en Python denominado Miniedit.
Mininet utiliza conmutadores virtuales que soporta el protocolo OpenFlow para
simular el comportamiento de las redes definidas por software. Incluye un
controlador propio con enrutamiento básico y permite que se conecte remotamente
un controlador externo como Ryu, OpenDayLight u ONOS, entre otros; este
controlador externo está ubicado en una máquina virtual instalado en el VirtualBox
(u otro software de virtualización que se use)
Información recomendable para analizar los comandos de Mininet se encuentra en
la página oficial de Mininet “Mininet Walkthrough” en
http://mininet.org/walkthrough/
2.5.1 Introducción al simulador Mininet

a.- Para conocer las opciones definidas en Mininet, se debe ingresar el comando
sudo mn –help como se observa en la figura 2.28.
sudo mn --help
Figura 2.28
b.- Para limpiar los registros del Mininet, ingrese el comando sudo mn -c, como
se ilustra en la figura 2.29.
sudo mn -c
Esta opción se debe realizar cada vez que se inicia una nueva simulación
Figura 2.29
2.5.2 Topologías definidas en el simulador Mininet

a.- Topología simple con dos hosts
Para volver a invocar a la topología simple con dos hosts de la figura 2.26 se debe
ingresar el comando sudo mn, como se ilustra en la figura 2.30.
sudo mn
Figura 2.30
Para comprobar que existe conexión desde el host h1 al host h2 y desde el host h2
al host h1 se debe ingresar el comando pingall desde el Mininet, como se ilustra en
la figura 2.31.
pingall
Figura 2.31
En el mensaje:
*** Ping: testing ping reachability
h1 -> h2
h2 -> h1
*** Results: 0% dropped (2/2 received)
Se verifica la conectividad entre ambos hosts (0% dropped), como se observa en la

figura 2.31
Para salir del Mininet se debe ingresar el comando exit; como se observa en la figura
2.32.
exit
Figura 2.32
b.- Topología lineal

Esta topología presenta k conmutadores SDN conectados en serie con n hosts
conectados a cada conmutador. En la figura 2.33 se ilustra esta topología lineal.
Figura 2.33
Consideremos la siguiente topología lineal con 3 conmutadores SDN conectados en

serie y en cada conmutador conectados 4 hosts; el comando es sudo mn --
topo=linear,k=3,n=4.
sudo mn --topo=linear,k=3,n=4
En la figura 2.34 se observa el comando ingresado para activar esta topología lineal
y las pruebas de conectividad entre todos los hosts con el comando pingall.
Figura 2.34
c.- Topología simple con k hosts

Esta topología presenta sólo un (01) conmutador SDN con k hosts conectados al
conmutador. Por ejemplo, una topología con solo un (1) conmutador conectando a
cinco (5) hosts se ilustra en la figura 2.35.
Figura 2.35
El comando para activar una topología simple con k=5 hosts conectado a un
conmutador SDN es sudo mn --topo=single,k=5, como se ilustra en la figura 2.36.
sudo mn --topo=single,k=5
Figura 2.36
La prueba de conectividad entre los cinco (5) host se realiza con el comando pingall
como se ilustra en la figura 2.37. Recordar que para salir de Mininet el comando es
exit.
Figura 2.37
d.- Topología tipo árbol

Esta topología presenta n niveles (depth) con f ramas (fanout). Consideremos la
topología tipo árbol con 4 niveles (depth=4) y 2 ramas (fanout=2); en la figura 2.38
se ilustra esta topología.
Figura 2.38
Esta red es de depth=4 niveles, con fanout=2 ramas, contiene 15 conmutadores

SDN (20+21+22+23=15):
Nivel 1: Conmutador S1 20 conmutadores SDN

Nivel 2: Conmutador S2 y S9 21 conmutadores SDN
Nivel 3: Conmutador S3, S6, S10 y S13 22 conmutadores SDN
Nivel 4: Conmutador S4, S5, S7, S8, S11, S12, S14 y S15 23 conmutadores SDN
El comando para activar esta topología tipo árbol que genera en total de 15
conmutadores SDN y 16 hosts es sudo mn --topo=tree,depth=4,fanout=2 como
se ilustra en la figura 2.39.
sudo mn --topo=tree,depth=4,fanout=2
Figura 2.39
Las pruebas de conectividad entre todos los hosts se realizan con el comando
pingall. Al final de la figura 2.39 se observa el mensaje de 0% de paquetes
eliminados: “0% dropped (240/240 received)”.
Para probar conectividad entre dos hosts de cualquier topología en el Mininet (por
ejemplo, host h1 con host h3) se debe ingresar el comando h1 ping h3 como se
ilustra en la figura 2.40. Para finalizar el envío de paquetes ICMP pulsar Control y la
tecla C en simultaneo.
h1 ping h3
Figura 2.40
Recordar que para limpiar los registros del Mininet se debe ingresa el comando sudo mn -c
2.6 MINIEDIT
2.6.1 Activación del MiniEdit
MiniEdit es una plataforma que presenta una interfaz gráfica para el diseño de la
topología de una red definida por software. Presenta servidores conteniendo el
sistema operativo de la red definida por software, denominados controladores (c) y
conmutadores SDN o OpenFlow (s). De manera remota se puede asociar a la SDN
diversos tipos de sistemas operativos de red como Ryu, OpenDayLight y ONOS.
Amplia información del MiniEdit en: http://www.brianlinkletter.com/how-to-use-
miniedit-mininets-graphical-user-interface/ .
MiniEdit está desarrollado en Python y Ubuntu 20.04.4 contiene el Python en su
versión 3 (y también la versión 2). Para verificar la versión del Ubuntu debe leer el
archivo os-release ubicado en el directorio /etc; como se observa en la figura 4.41.
cat /etc/os-release
Figura 2.41
Para verificar la versión de Python en Ubuntu 20.04.4 se debe ingresar el comando

python3 --version, como se observa en la figura 2.42.
python3 --version
Figura 2.42
Para activar MiniEdit se debe ingresar el directorio donde se ubica el archivo de

MiniEdit y ejecutar el comando sudo python3 ./miniedit.py como se observa en la
figura 2.43.
cd mininet
cd mininet
cd examples
sudo python3 ./miniedit.py
Figura 2.43
Al ejecutar este comando se obtiene el área de trabajo del MiniEdit como se observa
en la figura 2.44. Para formar una red coloque el cursor encima del ícono de
dispositivo de interconexión a utilizar y hacer un click encima; luego ubique el cursor
en el área en blanco de trabajo y hacer un click para que este dispositivo de
interconexión sea parte de su red a simular.
Representa al controlador SDN que contiene el sistema operativo de la red.
Representa al conmutador SDN con el protocolo OpenFlow.
Representa a un host que se conectará a un conmutador SDN.
Representa conexión en el plano de datos (azul) o plano de control (rojo).

Figura 2.44
2.6.2 Simulación con MiniEdit

Para iniciar el uso del MiniEdit se implementa una topología simple formado por un
(01) controlador c0, dos conmutadores SDN o OpenFlow s1 y s2, y cuatro (04) hosts
h1, h2, h3 y h4, como se ilustra en la figura 2.45.
Figura 2.45
Una vez defina la red a simular, el siguiente paso es ejecutar la simulación, Para ello
pulsar el indicar Run que se ubica en la parte inferior izquierda del MiniEdit, como
se observa en la figura 2.46.
Figura 2.46
Cada host en el MiniEdit tiene su propio terminal donde se puede ejecutar comandos
o activar aplicaciones como el Wireshark. Para abrir el terminal de un host, primero
se debe iniciar la simulación pulsando Run, hacer un click derecho encima del host
(por ejemplo, el host h1); y luego seleccionar “Terminal”, como se observa en las
figuras 2.47.
Figura 2.47
En la figura 4.48 se ilustra el terminal del host h1.

Figura 2.48
Por defecto, MiniEdit coloca al host h1 la dirección IP 10.0.0.1, al host h2 la dirección

IP 10.0.0.2, así sucesivamente. Para conocer el estado actual de la interfaz activa,
entre ellas su dirección IP, se debe ingresar el comando ifconfig en el respectivo
terminal del host, como se observa en la figura 2.49.
ifconfig
Figura 2.49
Es importante observar que la interfaz del host h1 es h1-eth0, para el host h2 es h2-
eth0, así sucesivamente.
Para mostrar una lista resumida de la interfaz activa, ingrese el comando ifconfig -
s, como se observa en la figura 2.50.
Ifconfig -s
Figura 2.50
Cambio de dirección IP en el host.- Para cambiar el número IP de un host, por

ejemplo, en el host1 con la nueva dirección 50.60.70.1/24, ingrese en el terminal del
host h1 el comando ifconfig h1-eth0 50.60.70.1 netmask 255.255.255.0 y para
verificar el cambio nuevamente ingresar el comando ifconfig, como se observa en
la figura 2.51. De manera similar se cambia las direcciones de los otros hosts; por
ejemplo, host h2 con 50.60.70.2, host h3 con 50.60.70.3 y host h4 con 50.60.70.4,
todas con máscara 255.255.255.0,
ifconfig h1-eth0 50.60.70.1 netmask 255.255.255.0

ifconfig
Figura 2.51
Para verificar que existe conexión entre los hosts se utiliza el comando ping. Por
ejemplo, para probar conexión desde el host h4 hacia el host h1, desde el terminal
del host h4 se debe ingresar el comando ping 50.60.70.1, como observa en la figura
2.52.
Recordar que para detener el envío de paquetes IP con el comando ping debe pulsar en simultaneo
CONTROL y la tecla C.
Figura 2.52
2.6.3 Wireshark con MiniEdit

El analizador de protocolos wireshark se activa desde la plataforma MiniEdit para
analizar el funcionamiento de los protocolos de los planos de datos y de control. Para
analizar los datos o protocolos que circulan entre los hosts y los conmutadores SDN
o OpenFlow (plano de datos) al que están conectados, se debe activar el wireshark
desde el terminal del host respectivo con el comando wireshark & (figura 2.53a); en
el wireshark seleccionar la interfaz a analizar, en este caso h1-eth0 (figura 2.53b);.
Luego en la parte superior del analizar wireshark seleccionar Capture y en la nueva
ventana emergente seleccionar Start (figura 2.53c).
Figura 2.53a
Figura 2.53b
Figura 2.53c
Análisis de tráfico de datos. - Para generar tráfico desde el host h3 al host h1 se

debe ejecutar el comando ping 50.60.70.1, como se ilustra en la figura 2.54.
Figura 2.54
Un aspecto importante que se captura ilustrada en la figura 2.54 es el tiempo que se

emplea en la ida y vuelta del primer paquete ICMP (llamado round-trip time ó rtt)
desde el host 3 hacia el host 1, que comparando con los demás rtt es mayor (aquí
se obtiene 5.42 ms). Esto se debe a que inicialmente las tablas de flujos de los
conmutadores SDN o OpenFlow están vacías (tablas de flujo reactivas); al llegar el
primer mensaje ICMP (producto del comando ping) el conmutador envía al
Controlador c0 el mensaje OpenFlow PACK_IN para que defina acciones respecto
al mensaje ICMP. Luego el Controlador c0 envía el mensaje OpenFlow PACK_OUT
a cada conmutador para que actualice sus tablas de flujo. En los siguientes
mensajes ICMP el tiempo de ida y vuelta es bastante menor ya que encontrarán las
tablas de flujo con valores adecuados para las acciones de envío del paquete ICMP.
En la figura 2.55 se ilustra la captura del tráfico entre h1 y h2 con el wireshark.
Figura 2.55
Análisis del plano de control.- Para analizar el protocolo OpenFlow (plano de

control) se debe activar el wireshark con el comando wireshark desde un nuevo
terminal del Ubuntu, como se observa en la figura 2.56a, de esta forma se capturará
mensajes OpenFlows entre el Controlador c0 con los conmutadores SDN o
OpenFlow que forma la red definida por software simulada. Desde la interfaz gráfica
del wireshark se debe seleccionar la interfaz Loopback: lo, como se observa en la
figura 2.56b. Luego en la parte superior del analizar wireshark seleccionar Capture
y en la nueva ventana emergente seleccionar Start, como se observa en la figura
2.56c.
Figura 2.56a
Figura 2.56b
Figura 2.56c
Se inicia la captura de los mensajes OpenFlow como se observa en la figura 2.57.

Se puede resaltar que por defecto el Mininet hace uso de protocolo OpenFlow en su
versión 1.0. Mininet soporta controladores como Ryu, OpenDayLight y ONOS, con
el protocolo OpenFlow versión 1.3 como se analizará en los capítulos siguientes.
Figura 2.57
2.6.4 Almacenamiento de la red simulada

Para almacenar la red SDN en su directorio de trabajo, se debe ubicar en la parte
superior izquierda del MiniEdit la opción File. En la nueva ventana emergente
seleccionar Save y luego escribir el nombre del archivo que contendrá la simulación,
por ejemplo, red_SDN_01; por defecto, en el proceso descrito, se almacena en
/home/unmsm/mininet/examples, como se observa en las figuras 2.58a y 2.58b.
Figura 2.58a
Figura 2.58b
Para recuperar el archivo almacenado, una vez activado el MiniEdit, ubicar en la

parte superior izquierda del MiniEdit la opción File, de la ventana emergente
seleccionar Open y luego el nombre del archivo a recuperar.
2.7 CLONACIÓN DE MÁQUINA VIRTUAL
Como la máquina virtual ubuntu_20.04.4 tiene instalado Mininet es adecuado clonar
esta máquina virtual para continuar con la instalación de los controladores Ryu,
OpenDayLight o ONOS. En caso de posibles fallas en la instalación de estos
controladores será sencillo y seguro volver a instalarlos a partir de la máquina virtual
original.
Para clonar la máquina virtual ubuntu_20.04.4 colocar el mouse encima de esta
máquina y hacer click derecho; en la nueva ventana emergente seleccionar “Clonar”
, como se observa en la figura 2.59.
Figura 2.59
En la nueva ventana emergente colocar el nuevo nombre de la máquina virtual, por

ejemplo, Ubuntu_20.04.4_UNMSM_Ryu y la ruta del directorio donde se instalará,
como se observa en la figura 2.60.
Figura 2.60
Se inicia el proceso de clonado de manera completa como se observa en las figuras

2.61a y 2.61b
Figura 2.61a
Figura 2.61b
En la figura 2.62 se observa la nueva máquina virtual

ubuntu_20.04.4_UNMSM_Ryu donde se instalará el controlador Ryu.
Figura 2.62
De manera similar es recomendable clonar la ubuntu_20.04.4 con los nombres

ubuntu_20.04.4_UNMSM_OpenDayLight y ubuntu_20.04.4_UNMSM_ONOS
para instalar los controlares OpenDayLight y ONOS respectivamente.
Capítulo 3. CONTROLADOR RYU
CAPÍTULO 3
CONTROLADOR RYU
3.1 CONTROLADOR RYU

Para implementar una red definida por software se necesitan tres componentes. La
primera son las aplicaciones SDN que facilitan la comunicación de comportamientos
y recursos necesarios con el controlador SDN a través de una interfaz de
programación de aplicaciones (API); el segundo es el controlador SDN que es una
entidad lógica que recibe órdenes desde las aplicaciones SDN y los transmite a los
dispositivos de interconexión o conmutadores SDN; y el tercero son los dispositivos
de interconexión o conmutadores SDN que son los responsables de controlar las
capacidades de reenvío y definir las trayectorias que siguen los datos en la SDN.
Para la implementación del segundo componente, uno de los controladores
utilizados es el controlador Ryu, que está implementado en el programa Python y
es de código abierto para las redes definidas por software, compatible con el
protocolo OpenFlow versiones 1.0, 1.2, 1.3, 1.4 y 1.5 y fue desarrollado por Nippon
Telegraph and Telephone (NTT). Como referencia Ruy proviene de la palabra
japonesa リュウ que significa “fluir” y está relacionado a un dragón japonés, uno
de los dioses del agua. El controlador Ryu proporciona componentes de software
con interfaces de programa de aplicación (API) bien definidas que facilitan a los
desarrolladores la creación de nuevas aplicaciones de control y administración de
red. En la figura 3.1 se muestra la arquitectura de Ryu [Shozi et al-2019].
Figura 3.1 Arquitectura de Ryu [Shozi et al-2019, pag. 5]

3.2 INSTALACIÓN DEL CONTROLADOR RYU

3.2.1 Instalación del Controlador Ryu en Ubuntu.
Ingresar a la máquina virtual donde se instalará el controlador de red Ryu; en este
caso la máquina ubuntu_20.04.4_UNMSM_Ryu, y pulsar Iniciar como se
observa en la figura 3.2a.
Figura 3.2a
Activar un terminal de Ubuntu y acceder al repositorio GitHub para clonar y

descargar el código del sistema operativo de red Ryu. Para ello, se debe ingresar el
siguiente comando sudo git clone https://github.com/osrg/ryu.git como se
observa en la figura 3.2.b.
sudo git clone https://github.com/osrg/ryu.git
Figura 3.2b
Durante el proceso de clonación de Ryu en la máquina virtual se ha creado un nuevo

directorio denominado ryu, como se observa en la figura 3.3.
Figura 3.3
Para iniciar la instalación de Ryu, primero ingresar al directorio ryu; notar que en
este directorio existe el archivo setup.py, luego ingresar el siguiente comando sudo
python3 ./setup.py install, como se observa en las figuras 3.4a y 3.4b.
cd ryu
ls
sudo python3 ./setup.py install
Figura 3.4a
Figura 3.4b
Finalmente, para instalar el controlador Ryu se debe ingresar el siguiente comando

sudo pip3 install nombre_del_paquete. Donde nombre_del_paquete se refiere a
cualquier paquete o biblioteca de Python, como Ryu. Por lo tanto, para instalar Ryu
se debe ingresar el comando sudo pip3 install ryu, como se observa en las figuras
3.5a y 3.5b.
sudo pip3 install ryu
Figura 3.5a
Figura 3.5b
Durante el proceso de instalación de Ryu se crea el directorio app conteniendo

algunas librerías como: conmutador o switch simple SDN (archivo simple_switch),
conmutador o switch con el Protocolo Spanning Tree-STP asociado (archivo
simple_switch_stp_13), entre otros.
Se observa también el archivo cbench que permite generar mensajes OpenFlow
tipo PACKET-IN. Cbench es un programa para probar controladores OpenFlow
mediante la generación de eventos de PACKET-IN para nuevos flujos. Cbench
emula un grupo de conmutadores SDN, que se conectan a un controlador, enviando
mensajes PACKET-IN. Notar que el directorio app está ubicado debajo del directorio
denominado también ryu; en la ruta es ryu/app, como se observa en la figura 3.6.
cd ryu
cd app
ls
Figura 3.6
El archivo simple_switch_stp_13.py es el recomendado para activar el Protocolo

Spanning Tree (STP). Observe que el actual directorio es /ryu/ryu/app.
3.2.2 Inicio del controlador Ryu en Ubuntu.
Para iniciar el controlador Ryu se debe ingresar el siguiente comando: sudo ryu-
manager ryu.app.simple_switch; para lanzar el simple_switch ubicado en la ruta
/ryu/ryu/app, como se observa en la figura 3.7.
sudo ryu-manager ryu.app.simple_switch
Figura 3.7
Active otro terminal donde se debe ejecutar mininet con una topología simple de un
(01) switch SDN, tres (03) hosts y un (01) controlador Ryu (controller remote), en
este nuevo terminal ingresar el comando sudo mn --topo single,3 --mac --switch
ovsk --controller remote. Con el comando pingall se verifica las conexiones entre
los tres (03) hosts. Se debe observar que en el primer terminal empieza a generarse
los mensajes PACK_IN al controlador Ryu, como se observa en la figura 3.8.
sudo mn --topo single,3 --mac --switch ovsk --controller remote
Figura 3.8
Para salir del mininet ingresar el comando quit; finalmente, desde el primer terminal
(ryu/ryu/app) pulsar la tecla Control y la tecla C en simultaneo.
Importante limpiar los registros internos del mininet con el comando sudo mn -c
3.2.3 Controlador Ryu en MiniEdit

Para realizar una topología un poco más compleja, se debe emplear los
conmutadores o switches con el protocolo Spanning Tree-STP
simple_switch_stp_13; para ello ingresar el siguiente comando: sudo ryu-
manager ryu.app.simple_switch_stp_13; desde la ruta /ryu/ryu/app, como se
observa en la figura 3.9
sudo ryu-manager ryu.app.simple_switch_stp_13
Figura 3.8
El controlador Ryu está funcionando; como se observa, el terminal está a la espera

de que se active la red defina por software desde MiniEdit. Ahora se debe activar la
red de datos SDN utilizando MiniEdit desde otro terminal en la ruta
mininet/mininet/examples con el comando sudo python3 ./miniedit.py. La red
que se va simular se observa en la figura 3.9.
Figura 3.9
Un primer paso es activar la interfaz de comando de línea-CLI y el protocolo

OpenFlow en la versión 1.3: OpenFlow 1.3. Para realizar lo anterior, desde la
interfaz gráfica de MiniEdit seleccionar “Edit” y en la nueva ventana emergente
seleccionar la opción “Preferences”.
Figura 3.10
Esta selección origina una nueva ventana emergente, como se observa en la figura
3.11a, donde se debe activar “Start CLI”, desactivar “OpenFlow 1.0” y activar
“OpenFlow 1.3”, luego pulsar “OK”, como se observa en la figura 3.11b.
Figura 3.11a
Figura 3.11b
Para que el controlador acceda remotamente al Controlador Ryu se debe ubicar el

mouse encima del controlador “c0”, click derecho y seleccionar “Properties”, como
Figura 3.12
En la nueva ventana “Controller Details” en la opción “Controller Type” seleccionar

“Remote Controller”, como se observan en las figuras 3.13a y 3.13b.
Figura 3.13a Figura 3.13b
Desde MiniEdit seleccionar la opción Run que está ubicado en la parte

inferior izquierda del espacio de trabajo de MiniEdit.
Finalmente, se observa desde la primera ventana donde se lanzó el sistema
operativo de red Ryu se está ejecutando, en la segunda ventana donde se activó
MiniEdit está disponible para ingresar comandos del mininet; por ejemplo, ejecutar
el comando pingall para verificar el funcionamiento de la red con Ryu y el MiniEdit

con la red simulada, como se observa en la figura 3.14.
Figura 3.14
3.2.4 Controlador Ryu y Wireshark

Desde el terminal de uno de los hosts, por ejemplo, el host h1, se debe activar el
wireshark con el comando sudo wireshark & para analizar los datos desde o hacia
este host; generar tráfico con el comando ping, por ejemplo, desde el host h5 al host
h1 con el comando ping 10.0.0.1, como se ilustra en la figura 3.15.
De manera similar, desde un nuevo terminal desde el Ubuntu se debe activar el
wireshark con el comando sudo wireshark para analizar el protocolo OpenFlow
entre el controlador y los conmutadores SDN; como se ilustra en la figura 3.16.
Figura 3.15
Figura 3.16
3.3 INSTALACIÓN DE LA APLICACIÓN FLOWMANAGER DE RYU

Una las características de SDN es la programabilidad; es decir, desde la capa de
aplicación del modelo SDN se dispone de aplicaciones (cliente) que acceden al
controlador Ryu (servidor) para conocer el estado y realizar reconfiguración de la
red.
Una de las aplicaciones disponible para administrador el control de los flujos en una
red que soporta el protocolo OpenFlow con el controlador Ryu es el FlowManager
y permite:
✓ Agregar/modificar/eliminar entradas de flujo en tablas de flujo.

✓ Agregar/modificar/eliminar tablas de grupo y medidores.
✓ Copia de seguridad/restauración de tablas de conmutador a / desde
unidad local.
✓ Ver tablas de flujo, tablas de grupo y medidores.
✓ Ver estadísticas del conmutador.
✓ Ver topología de red.
Para bajar y clonar en la PC de trabajo el gestor de flujo para Ryu, denominado

FlowManager se debe ingresar el comando sudo git clone
https://github.com/martimy/flowmanager, como se observa en la figura 3.17.
sudo git clone https://github.com/martimy/flowmanager
Figura 3.17
Para activar el gestor de flujo conjuntamente con el controlador Ryu se debe ingresar
el comando sudo ryu-manager --observe-links ~/flowmanager/flowmanager.py
ryu.app.simple_switch_stp_13 dentro del directorio ryu/ryu/app como se observa
en la figura 3.18
cd ryu
cd ryu
cd app
sudo ryu-manager --observe-links ~/flowmanager/flowmanager.py ryu.app.simple_switch_stp_13
Siempre que se inicie una nueva simulación limpiar mininet con sudo mn -c
Figura 3.18
En un nuevo terminal activar el MiniEdit para definir la topología para su simulación;

en el directorio mininet/mininet/examples ingrese el comando sudo python3
./miniedit.py como se observa en la figura 3.19.
cd mininet
cd mininet
cd examples
Figura 3.19
Activar la red a simular seleccionando la opción Run. Probar conectividad entre

todos los hosts con el comando pingall, como se observa en la figura 3.20.
Figura 3.20
Ahora para acceder a la aplicación FlowManager, se debe ingresar al Mozilla Firefox

la dirección localhost:8080/home/index.html como se observa en la figura 3.21 a
y en la figura 3.21b se tiene una primera visión de la topología de la red simulada.
localhost:8080/home/index.html
Figura 3.21a
Figura 3.21b
3.4 REDES DUAL STACK SDN CON RYU: IPv4/IPv6

Nuevamente, en un primer terminal del Ubuntu se lanza el controlador ryu con la
aplicación simple_switch_stp_13. En un segundo terminal de Ubuntu se lanza el
miniedit, con el comando sudo python3 ./miniedit.py, como se observa en las
figura 3.22.
1er terminal
2do terminal
Figura 3.22
Ahora, en el miniedit se debe de activar el OpenFlow 1.3 que soporta IPv6 como se
detalló en la figura 3.11 y configurar el controlador para que remotamente acceda al
controlador Ryu como se detalló en la figura 3.13. En la figura 3.23 se muestra la
red SDN considerada con OpenFlow 1.3 y controlador Ryu. Para verificar
conectividad entre todos los hosts utilizar el comando pingall.
h2: 2001:abc9:20cd::1002/64 h5: 2001:abc9:20cd::1005/64
h1: 2001:abc9:20cd::1001/64 h3: 2001:abc9:20cd::1003/64 h4: 2001:abc9:20cd::1004/64 h6: 2001:abc9:20cd::1006/64
Figura 3.23
Las direcciones IPv6 de la red dual stack se indica a continuación y la red dual stack
• Host h1 → 2001:abc9:20cd::1001/64
• Host h2 → 2001:abc9:20cd::1002/64
• Host h3 → 2001:abc9:20cd::1003/64
• Host h4 → 2001:abc9:20cd::1004/64
• Host h5 → 2001:abc9:20cd::1005/64
• Host h6 → 2001:abc9:20cd::1006/64
Para configurar las direcciones IPv6 a cada host, desde el segundo terminal de
Ubuntu, se ingresa el comando <nombre del host> ifconfig <nombre de interfaz>
inet6 add <dirección IPv6>; por ejemplo, para colocar en el host 1 la dirección IPv6
2001:abc9:20cd::1001/64 se debe ingresar después del indicador de mininet> el
comando h1 ifconfig h1-eth0 inet6 add 2001:abc9:20cd::1001/64. Para verificar

los cambios realizados ingresar el comando h1 ifconfig, como se observa en la
figura 3.24.
h1 ifconfig h1-eth0 inet6 add 2001:abc9:20cd::1001/64

h1 ifconfig
Dirección en IPv4
Dirección en IPv6
Figura 3.24
De manera similar se asigna las direcciones IPv6 en los host h2, h3, h4, h5 y h6 con
las direcciones indicadas en la figura 3.23. Esta configuración se observa en la figura
3.25.

Figura 3.25
Para verificar la conectividad entre los hosts en IPv6 se usa el comando ping; por
ejemplo, entre el host h1 y el host h6 el comando completo es h1 ping
2001:abc9:20cd::1006 y entre el host h1 y el host h4 el comando completo es h1
ping 2001:abc9:20cd::1004, como se observa en la figura 2.26.
Figura 3.26
Desde el terminal de mininet con el comando xterm h1 h2 se activan los terminales

de los hosts h1 y h2 como se observa en la figura 3.27.
xterm h1 h2
Figura 3.27
En el terminal del host h2 se activa el wireshark con el comando wireshask & y

desde el terminal del host h1 de realiza el ping hacia el host h2 con el comando
ping 2001:abc9:20cd::1002, como se observa en las figuras 3.28 y 3.29.
Figura 3.28
Figura 3.29
La captura de los datagramas IPv6 se observa en la figura 3.30; en la captura se

verifica que el campo Type de la cabecera de la trama Ethernet está en el valor
0x86DDH (en hexadecimal) indicando que el protocolo que está encapsulando la
trama Ethernet es el datagrama IPv6.
Figura 3.30
BIBLIOGRAFÍA
[Shozi-2019] T. Shozi, S. Dlamini, P. Mudali and M. O. Adigun, "An SDN Solution for
Performance Improvement in Dedicated Wide-Area Networks", 2019 Conference on
Information Communications Technology and Society (ICTAS), 2019, pp. 1-6, doi:
10.1109/ICTAS.2019.8703613.
[Ryu] “Ryu SDN Framework: Using OpenFlow 1.3”
Capítulo 4. CONTROLADOR OPENDAYLIGHT
CAPÍTULO 4
CONTROLADOR OPENDAYLIGHT
4.1 CONTROLADOR OPENDAYLIGHT

OpenDayLight (ODL) es el sistema operativo de red abierta modular para
personalizar y automatizar redes de cualquier tamaño y escala y está escrito en el
lenguaje Java. El proyecto OpenDaylight surgió del movimiento SDN, con un
enfoque claro en la programabilidad de la red. Fue diseñado desde el principio como
base para soluciones comerciales que abordan una variedad de casos de uso en el
entorno de red existente (https://www.opendaylight.org/)
OpenDaylight centraliza lógicamente el control programático de los dispositivos
físicos y virtuales en su red, controla los dispositivos con protocolos abiertos
estándar y proporciona abstracciones de alto nivel de sus capacidades para que los
ingenieros y desarrolladores de redes experimentados puedan crear nuevas
aplicaciones para personalizar la configuración y administración de la red.
La herramienta Apache Karaf proporciona un mecanismo de ejecución ligero para
instalar las características de Karaf que desea implementar y está incluido en el
software de la plataforma OpenDaylight. De forma predeterminada, OpenDaylight no
tiene funciones preinstaladas, esto significa que después de instalar OpenDaylight,
se debe instalar las funciones seleccionadas mediante la consola Karaf para
expandir las capacidades de red.
La herramienta DLUX es una interfaz basada en web que OpenDaylight le
proporciona para administrar su red. DLUX extrae información de la topología de
OpenDaylight y de las bases de datos del host para mostrar la siguiente información:
la red, estadísticas de flujo y ubicación de los hosts. Para asegurar que la topología
muestre todos los detalles se debe habilitar la función odl-l2switch-switch en Karaf.
La arquitectura de OpenDayLight presenta tres niveles. En el nivel más alto se
encuentran las aplicaciones para la gestión de la red y hacen uso de la API
Northbound para comunicarse con el controlador. En el nivel intermedio se
encuentra la plataforma del controlador basado en MD-SAL (Model-Driven Service
Abstraction Layer). En el nivel más bajo se encuentran los dispositivos de red y se
comunican con el controlador a través del API Southbound.
Las versiones de OpenDayLight sigue una nomenclatura basada en los elementos
de la tabla periódica. La primera versión liberada fue en febrero de 2014 y se le
asignó el nombre Hygrogen.
La documentación oficial de cada versión se encuentra en
https://docs.opendaylight.org/en/stable-<versión>, donde <versión> es el
nombre de la versión a ser analizado. Por ejemplo, boron u oxygen; para este último
es https://docs.opendaylight.org/en/stable-oxygen
4.2 ACTUALIZACIÓN DEL SISTEMA OPERATIVO

Para actualizar el sistema operativo Ubuntu se debe ejecutar apt-get, el efecto es
actualizar la lista de paquetes disponibles; de esta manera se conocerá las nuevas
versiones de los paquetes y sus dependencias, como se muestra en la figura 4.1.
sudo apt-get -y update
Figura 4.1
Ahora se debe actualizar los paquetes a través de la opción de upgrade, como se

muestra en las figuras 4.2a y después de algunos minutos, dependiendo de su
computadora personal, se tendrá 4.2b.
sudo apt-get -y upgrade
Figura 4.2a
Figura 4.2b
4.3 INSTALACIÓN DE JAVA JRE VERSION 8

En su sistema operativo de trabajo pueden existir varias versiones de Java
instalados. Se debe configurar una versión por defecto indicando la trayectoria o
PATH respectivo. El archivo environment ubicado en el directorio /etc contiene
todos los PATH. Se puede observar su contenido usando cualquier editor. Ubicar el
directorio /etc, como se muestra en la figura 4.3.
cd ..
cd ..
cd etc
Figura 4.3
O directamente con el comando cd /etc, como se muestra en la figura 4.4.
cd /etc
Figura 4.4
En ambos casos, se debe leer el contenido del archivo environment con el comando
cat environment, como se muestra en la figura 4.5.
Figura 4.5
Se observa que este archivo environment en PATH no contiene la variable

JAVA_HOME.
Retornar al directorio de trabajo con cd /home/unmsm, como se muestra en la figura
4.6.
cd /home/unmsm
Figura 4.6
Instalación de Java versión 8

OpenDayLight funciona en un ecosistema Java. OpenDayLight requiere un entorno
Java (JRE) para ejecutarse. El comando sudo apt-get -y install openjdk-8-jre
instala JAVA 8 JRE que es el que utiliza OpenDayLight, como se muestra en las
figuras 4.7a y 4.7b.
sudo apt-get -y install openjdk-8-jre

Figura 4.7a
Figura 4.7b
Utilizar el comando update-alternatives para establecer el Java predeterminado en

JAVA 8. update-alternatives presenta una lista de versiones de Java instaladas y
permite seleccionar la versión predeterminada deseada. Si update-alternatives
proporciona una lista de versiones, seleccione JAVA 8 de la lista. Como se observa
en la figura 4.8 no hay alternativas.
sudo update-alternatives --config java
Figura 4.8
update-alternatives genera una información útil que es la ruta completa del

ejecutable JAVA. Como se observa en la figura 4.8, la ruta es /usr/lib/jvm/java-8-
openjdk-amd64/jre/bin/java.
Para observar el contenido de esta ruta ingresar el comando ls /usr/lib/jvm/java-8-
openjdk-amd64/jre como se observa en la figura 4.9.
ls /usr/lib/jvm/java-8-openjdk-amd64/jre
Figura 4.9
4.4 ESTABLECER LA VARIABLE JAVA_HOME EN JAVA VERSIÓN 8

OpenDayLight requiere que la variable de entorno JAVA_HOME refleje la ubicación
de todo el conjunto de herramientas JAVA, y no solo del ejecutable JAVA. Por esa
razón, de la ruta anterior /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java sólo se
considera /usr/lib/jvm/java-8-openjdk-amd64/jre. Esto establece JAVA_HOME en
la ubicación del JREN es decir JAVA_HOME=“/usr/lib/jvm/java-8-openjdk-
amd64/jre”.
Para definir la variable de entorno JAVA_HOME se debe ingresar al archivo
environment con el comando sudo nano /etc/environment como se observa en la
figura 4.10.
sudo nano /etc/environment
Figura 4.10
En este archivo no se encuentra la variable JAVA_HOME como se observa en la

figura 4.11.
Figura 4.11
A este archivo se debe adicionar la variable JAVA_HOME=“/usr/lib/jvm/java-8-

openjdk-amd64/jre”, como se observa en la figura 4.12.
Figura 4.12
Para guardar la variable ingresada pulsar en simultaneo las teclas Control y O

(pulsar Enter para realizar el guardado con el mismo nombre), luego Control y X.
Para mantener los cambios que se hicieron a la variable de entorno se debe ejecutar
el comando source /etc/environment, como se observa en la figura 4.13.
source /etc/environment
Figura 4.13
Luego, para verificar que está definido la variable de entorno ingresar el comando
echo, como se observa en la figura 4.14.
echo $JAVA_HOME
Figura 4.14
Para verificar la versión de Java en el sistema operativo ingresar el comando java -

version, como se observa en la figura 4.15.
java -version
Figura 4.15
Para conocer todas las versiones de java instalados se debe ingresar el comando
sudo update-alternatives –config java. Como se observa en la figura 4.16 sólo
existe uno, la versión 8.
Figura 4.16
4.5 INSTALACIÓN DE JAVA JRE VERSION 11 Y LA VARIABLE JAVA_HOME

Recomienda omitir: El opendaylight con karaf-0.8.4 usa java versión 8.
Se debe considerar que el opendaylight con el karaf-0.8.4 requiere de java en la
versión 8. Sólo como referencia se detalla la opción de actualizar Ubuntu con Java
en la versión 11 (https://comoinstalar.me/como-instalar-java-en-ubuntu-20-04-lts/)
Actualizar la lista de paquetes disponible con el comando sudo apt update, como
sudo apt update
Figura 4.17
La instalación de java en la versión 11 empieza al ingresar el comando sudo apt

install -y default-jre, como se observa en las figuras 4.18a y 4.18b.
sudo apt install -y default-jre
Figura 4.18a
Figura 4.18b
Para conocer las versiones de java instaladas se debe ingresar el comando sudo
update-alternatives –config java. Como se observa en la figura 4.19 ahora existen
dos versiones, la versión 11 y la 8.
Figura 4.19
Por defecto se tiene activado java en la versión 11 en modo automático (el asterisco
en la primera fila así lo indica). Si se desea activar java en la versión 8 colocar el
número 2 y pulsar ENTER.
Como se observa en la figura 4.14 la variable JAVA_HOME tiene el valor
/usr/lib/jvm/java-8-openjdk-amd64/jre que corresponde a java en la versión 8. De
la figura 4.19 se observa la ruta para java en la versión 11, /usr/lib/jvm/java-11-
openjdk-amd64/bin/java. Todas las herramientas de java en la versión 11 está
indica en el nuevo valor de la variable JAVA_HOME=“/usr/lib/jvm/java-8-openjdk-
amd64/”.
Nuevamente, para definir la variable de entorno JAVA_HOME para java versión 11
se debe modificar el archivo environment como se observa en la figura 4.20.
sudo nano /etc/environment

Figura 4.20
En este archivo se debe actualizar la variable JAVA_HOME=“/usr/lib/jvm/java-11-

openjdk-amd64/”, como se observa en la figura 4.21.
Figura 4.21
Para guardar la variable ingresada pulsar en simultaneo las teclas Control y O

(pulsar Enter para realizar el guardado con el mismo nombre), luego Control y X.
Para mantener los cambios que se hicieron a la variable de entorno se debe ejecutar
el comando source /etc/environment, como se observa en la figura 4.22.
source /etc/environment
Figura 4.22
Luego, para verificar que está definido la variable de entorno ingresar el comando
echo $JAVA_HOME, como se observa en la figura 4.23.
echo $JAVA_HOME
Figura 4.23
En este punto se tiene java instalado en la versión 8 y 11, activado la versión 11
Resumen de activación de JAVA versión 8 para opendaylight con karaf-0.8.4

En este punto de la instalación se tiene instalados java en la versión 8 y 11. Para
instalar el controlador opendaylight se debe considerar el entorno de ejecución
karaf. Se selecciona karaf-0.8.4, esta versión de karaf requiere que java esté en la
versión 8. Para seleccionar java versión 8 por defecto, se debe ingresar el comando
sudo update-alternatives --config java y seleccionar la opción 2 para java versión
8 como se observa en la figura 4.24.
Figura 4.24
El valor de la variable JAVA_HOME se debe restaurar con el valor

“/usr/lib/jvm/java-8-openjdk-amd64/jre”, para realizar este cambio se debe
ingresar el comando sudo nano /etc/environment y luego modificar el valor de la
variable JAVA_HOME como se observa en la figura 4.12.
En este punto se tiene java instalado en la versión 8 y 11, activado la versión 8

para trabajar con karaf-0.8.4
4.6 DESCARGA DEL ARCHIVO TAR.GZ OPENDAYLIGHT

Ir a la página web de OpenDayLight: https://opendaylight.org, como se observa en
la figura 4.25.
Figura 4.25
Para acceder a las diversiones versiones del OpenDayLight seleccionar Learn More
, como se observa en la figura 4.26.
Figura 4.26
Seleccionar la opción OpenDayLight Downloads, como se observa en la figura

4.27.
Figura 4.27
Seleccionar la opción OpenDayLight (Nitrogen and Oxygen), como se observa en

la figura 4.28.
Figura 4.28
Seleccionar la opción 0.8.4/, como se observa en la figura 4.29.
Figura 4.29
Seleccionar la opción karaf-0.8.4.tar.gz, como se observa en la figura 4.30.
Figura 4.30
La descarga se inicia como se observa en la figura 4.31. En la carpeta Descarga se

almacena el archivo karaf-0.8.4.tar.gz.
Figura 4.31
Ingresando a la carpeta Descargas se tiene el archivo karaf-0.8.4.tar.gz

descargado, como se observa en la figura 4.32.
Figura 4.32
4.7 INSTALACIÓN DE OPENDAYLIGHT

Para un mejor orden en el proceso de instalación se va crear un directorio o carpeta
denominado opendaylight con el comando mkdir opendaylight. En esta carpeta
se copiará el archivo karaf-0.8.4.tar.gz para posteriormente instalar el
OpenDayLight, como se observa en la figura 4.33.
ls
mkdir opendaylight
ls
cd opendaylight
Figura 4.33
En este directorio o carpeta se copiará el archivo karaf-0.8.4.tar.gz en el directorio

creado opendaylight; con el comando ls se verifica que la copia fue acertada como
cp /home/unmsm/Descargas/karaf-0.8.4.tar.gz karaf-0.8.4.tar.gz
ls
Figura 4.34
Instalación del Controlador OpenDayLight

Iniciemos la instalación del Controlador OpenDayLight desempaquetando el archivo
karaf-0.8.4.tar.gz como se observa en la figura 4.35.
tar -zxvf karaf-0.8.4.tar.gz

Figura 4.35
El comando ls muestra el directorio creado karaf-0.8.4, luego se ingresa a este

directorio con el comando cd karaf-0.8.4 y se observa el directorio bin desde donde
se lanzará el controlador opendaylight, como se observa en la figura 4.36.
ls
cd karaf-0.8.4
ls
Figura 4.36
4.8 INICIO DE OPENDAYLIGHT

El archivo ejecutable de OpenDayLight denominado karaf se encuentra en el
directorio: /opendaylight/karaf-0.8.4/bin. Desde este directorio bin se debe
ejecutar el comando sudo ./karaf como se observa en la figura 4.37.
cd bin
sudo ./karaf
Figura 4.37
Instalar las características básicas de karaf

OpenDayLight no incluye características instaladas por defecto; para instalar
algunas de ellas se debe usar el comando feature:install <características 1 >. Es
posible habilitar más características adicionando a continuación o repitiendo el
comando anterior: feature:install <características 1 > <características 2 >
<características 3 >.
Un resumen de las características de OpenDayLight se obtiene en:
✓ Install OpenDaylight on Ubuntu 20.04 LTS (All Features, Any Version) (soban.ski)
https://john.soban.ski/install-opendaylight-ubuntu-lts-fast.html
✓ Getting Started Guide — OpenDaylight Documentation Phosphorus documentation
docs.opendaylight.org/en/latest/getting-started-guide/index.html
✓ Installing OpenDaylight — OpenDaylight Documentation Oxygen documentation
docs.opendaylight.org/en/stable-oxygen/getting-started-guide/installing_opendaylight.html
✓ Installing OpenDaylight — OpenDaylight Documentation Nitrogen documentation
docs.opendaylight.org/en/stable-nitrogen/getting-started-guide/installing_opendaylight.html#id1
Para conocer la lista completa de las características de Karaf instaladas se debe

ejecutar el comando feature:list -i, como se muestra en la figura 4.38.
Figura 4.38 Características de Karaf instaladas
Se debe instalar las siguientes funciones que se muestran en la figura 4.39.
feature:install odl-restconf
feature:install odl-mdsal-apidocs
feature:install odl-dluxapps-applications
feature:install odl-dluxapps-topology
feature:install odl-dluxapps-nodes
feature:install odl-l2switch-all → Si existe un error continue con la instalación
feature:install odl-l2switch-switch-ui
feature:install odl-l2switch-switch
feature:install odl-l2switch-all → Volver a ejecutar la función
Figura 4.39 Instalación de las funciones de Karaf
odl-restconf .- Habilita el acceso de la API REST a MD-SAL incluyendo datos

almacenados.
odl-l2switch-switch-ui .- Proporciona reenvío L2 (Ethernet) a través de switches
OpenFlow conectados y soporte para seguimiento de host. Para ejecutar L2 Switch
dentro de la distribución OpenDaylight, simplemente instale la función odl-l2switch-
switch-ui;
odl-mdsal-apidocs .- Desde que OpenDayLight-ODL adoptó el enfoque MD-SAL
(Model Driven Service Abstraction Layer, Capa de activación de servicio de unidad
de módulo), ciertas configuraciones estáticas como la creación de flujo estático, la
actualización/eliminación de flujo de la interfaz de usuario de ODL, etc., se han
reemplazado con un enfoque mucho más abstracto.
odl-dluxapps-applications.- Proporciona una interfaz gráfica de usuario intuitiva
para OpenDaylight.
odl-l2switch-switch.- Para asegurar que la topología muestre todos los detalles se

debe habilitar la función odl-l2switch-switch en Karaf.
odl-dluxapps-topology.- Aplicación de topología básica. Muestra nodos y enlaces
de topología de openflow (flujo: 1).
Una vez finalizado con la instalación de las funciones en OpenDayLight salir del
terminal donde está ejecutando el controlador con el comando logout. Luego
desde el terminal de Ubuntu borrar los registros internos del mininet con sudo
mn -c
4.9 SIMULACIÓN DE UNA RED SDN CON OPENDAYLIGHT

En este punto se tiene OpenDayLight con las funciones instaladas. Nuevamente se
debe activar el controlador OpenDayLight, para ello se debe ejecutar el comando
sudo ./karaf desde el directorio opendaylight/karaf-0.8.4/bin como se observa en
la figura 4.40a.
Figura 4.40a Controlador OpenDayLight activado
Utilizando el Miniedit se define la red SDN a simular con el controlador

OpenDayLight como se ilustra en las figuras 4.40b, 4.40c, 4.40d, 4.40e y 4.40f y
4.40g
Figura 4.40b Activar Miniedit
Figura 4.40c Topología de la red a simular
Figura 4.40d Seleccionar CLI y OpenFlow 1.3
Figura 4.40e Seleccionar Controlador Remoto en 127.0.0.1

Figura 4.40f Simulando la red
Figura 4.40g Probando conectividad entre todos los hosts
Aplicación de gestión del controlador OpenDayLight

El OpenDayLight contiene un servidor Web para observar la red SDN implementada.
El ingreso a este servidor desde un cliente se realiza desde el navegador web
Firefox ubicado en la máquina virtual que contiene el controlador OpenDayLight,
ingresando la dirección: http://127.0.0.1:8181/index.html. El número IP es donde
se ubica el Controlador, en este caso es el 127.0.0.1 seguido del puerto del servidor
que está en el valor 8181. Al ingresar al servidor web del OpenDayLight se observa
la ventana que se muestra en la figura 4.41; se debe ingresar en esta ventana como
login y password la palabra admin.
Figura 4.41 Aplicación de gestión del Controlador OpenDayLight
Al ingresar a la aplicación del gestor de controlador OpenDayLight se presenta la

página web con todas las opciones definidas, como se muestra en la figura 4.42
Figura 4.42 Aplicación de gestión del Controlador OpenDayLight
Seleccionar la opción Topology ubicado en el lado izquierdo superior de la

aplicación para visualizar la topología de la red. Pulsando Reload se refresca
la topología visualizada. En la figura 4.43 se observa la topología de la red SDN
simulada.
Es importante realizar el pingall para visualizar la red SDN simulada.
Figura 4.43 Visualización de la red SDN simulada
4.10 OBSERVACIONES COMPLEMENTARIAS

a.- Puede ocurrir que al iniciar la pantalla del Ubuntu esté siempre de color negro,
esto es debido a la resolución de la pantalla inadecuada. Se recomienda
redimensionar la pantalla seleccionado la opción Ver, luego Pantalla virtual y
finalmente Redimencionar a 1152x864, como se muestra en la figura 4.44
Figura 4.44 Redimencionar la pantalla en 1152x864
b.- Cada vez que inicia una simulación, debe previamente limpiar todos los registros
internos del mininet con el comando sudo mn -c .
RESUMEN
1.- Verificar que el mininet esté funcionando correctamente con el comando
sudo mn --test pingall
2.- Antes de iniciar una simulación en mininet, se debe limpiar los registros
internos del simulador con el comando sudo mn -c
3.- Activar en un terminal el controlador opendaylight con el comando sudo

./karaf
4.- Activar otro terminal para Ingresar al miniedit con el comando sudo python3
./miniedit.py y realizar la topología a simular, previamente configurar el
controlador remoto y habilitar los comandos CLI y el protocolo OpenFlow
versión 1.3
5.- Activar la aplicación de gestión del controlador OpenDayLight desde el

navegador Firefox para visualizar la topología de red en la dirección:
http://127.0.0.1:8181/index.html
En la red simulada realizar el pingall y recargar la aplicación con el icono de
Reload ubicado en la aplicación.
BIBLIOGRAFÍA
1. Install OpenDaylight on Ubuntu 20.04 LTS (All Features, Any Version)
https://john.soban.ski/install-opendaylight-ubuntu-lts-fast.html
2.- Working with Dlux

https://nexus.opendaylight.org/content/sites/site/org.opendaylight.docs/master/
userguide/manuals/userguide/bk-user-guide/content/_working_with_dlux.html
Capítulo 5. CONTROLADOR ONOS
CAPÍTULO 5
CONTROLADOR ONOS
5.1 CONTROLADOR ONOS

ONOS es el sistema operativo de red abierta (ONOS, Open Network Operating
System) de la Red Definida por Software-SDN y proporciona el plano de control para
la gestión de los conmutadores que soportan el protocolo OpenFlow, así como de
sus enlaces. ONOS promueve la innovación facilitando a los usuarios finales la
creación de nuevas aplicaciones de red sin necesidad de alterar los dispositivos del
plano de datos. El kernel, los principales servicios y las aplicaciones de ONOS están
escrito en Java.
ONOS se ha desarrollado con los siguientes objetivos [Koshibe-2016]]: Código
modular, el proyecto se compone por distintos subproyectos independientes. Hace
uso de las características de Maven que ofrece una organización jerárquica de sus
archivos. Configurable, permite cargar y descargar varias funciones, ya sea al inicio
o en tiempo de ejecución gracias a Karaf. Delimitación, ofrece límites claros entre
sus subproyectos para facilitar la modularidad; los módulos orientados a la red
interactúan con el núcleo o control a través de una API hacia el sur (proveedor) y el
núcleo o control con las aplicaciones a través de la API hacia el norte (consumidor).
La API hacia el norte proporciona aplicaciones con abstracciones que describen los
componentes y las propiedades de la red, de modo que puedan definir sus acciones
deseadas en términos de política en lugar de mecanismo. Agnóstico de protocolo,
si ONOS requiere nuevos protocolos debería de crear un nuevo módulo orientado a
la red relacionado con el API hacia el sur como un complemento sin alterar al
sistema.
Para instalar ONOS se requiere Java JDK, Maven, Apache Karaf 3.0.5.
Amplia información sobre onos en:
https://wiki.onosproject.org/display/ONOS/Downloads
5.2 INSTALACIÓN DEL CONTROLADOR ONOS
5.2.1 Actualización del Ubuntu
El primer paso es descargar información del paquete de todas las fuentes
configuradas; es decir, desde la Internet, con el comando sudo apt-get update.
Luego para instalar las actualizaciones disponibles de todos los paquetes en el
sistema desde las fuentes configuradas se debe ingresar el comando sudo apt-get
upgrade, como se observa en las figuras 5.1a y 5.1b.
sudo apt-get update

sudo apt-get upgrade
Capítulo 6. SCRIPT DE MININET EN PYTHON
Figura 5.1a
Figura 5.1b
5.2.2 Instalación de Java JDK

Es recomendable proporcionar una abstracción de los repositorios apt utilizados
para administrar fácilmente su distribución y las fuentes de software de proveedores
de software independientes. Para instalar Java en Ubuntu primero se debe de
ingresar el comando sudo apt-get install software-properties-common como se
observa en la figura 5.2.
sudo apt-get install software-properties-common

Figura 5.2
Se ha creado un script de instalación que descarga e instala automáticamente el

paquete Oracle JDK y establece Java como la versión predeterminada de Java
(configurando JAVA_HOME, etc.) en un sistema basado en Ubuntu de 64 bits. Para
realizar esta instalación se debe ingresar el comando sudo add-apt-repository
ppa:linuxuprising/java, como se observa en la figura 5.3. El efecto es agregar el
repositorio PPA de LinuxUprising Java a sus fuentes de software e instalar Oracle
Java en Ubuntu (PPA, Personal Package Archive, es un repositorio o almacén de
archivos personal hospedado en Launchpad).
sudo add-apt-repository ppa:linuxuprising/java
Figura 5.3
Nuevamente, de descarga la información del paquete de todas las fuentes

configuradas; es decir, desde la Internet, con el comando sudo apt-get update,
como se observa en la figura 5.4. Este paso es previo a la instalación Java.
sudo apt-get update
Figura 5.4
Se debe observar la versión de Java en el Ubuntu con el comando java -version,

como se observa en la figura 5.5.
java -version
Figura 5.5
Como se observa, Java no está instalado en el Ubuntu.

Algunas plataformas necesitan Java y JVM (la máquina virtual de Java) por lo que
se requiere la instalación de Java Runtime (JRE) y del kit de desarrollo de Java (JDK)
[B. Hogan-2020]; el comando para instalar JRE es sudo apt install default-jre. Para
instalar JDK que permitirá compilar y ejecutar algunos programas específicos
basados en Java es sudo apt install default-jdk. En la figura 5.6 se observa la
instalación de JDK.
sudo apt install default-jdk

Figura 5.6
Ahora se tiene instalado Java y para conocer la versión instalada se usa el comando
java -version; como se observa en la figura 5.7 la versión es 11.0.15.
java -version
Figura 5.7
Se puede disponer de varias versiones de Java instalado en la PC de trabajo, para

asegurar que una versión de Java en particular se ejecute por defecto, se debe
ingresar el comando sudo update-alternatives --config java para determinar la
ubicación de la instalación de Java, como se observa en la figura 5.8.

Figura 5.8
Del resultado al ejecutar el comando sudo update-alternatives --config java se

obtiene la ruta donde esta Java (no considerar a partir de /bin): /usr/lib/jvm/java-
11-openjdk-amd64.
Como recién se tiene instalado Java verifiquemos el estado de la variable de entorno
JAVA_HOME con el comando echo $JAVA_HOME, como se observa en la figura
5.9 no está disponible.
echo $JAVA_HOME
Figura 5.9
Ahora, se debe añadir JAVA_HOME a las variables de entorno de Ubuntu indicando

su ruta, para ello ingresar el comando export JAVA_HOME=/usr/lib/jvm/java-11-
openjdk-amd64, como se observa en la figura 5.10.
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
Figura 5.10
Se verifica nuevamente el estado de la variable de entorno JAVA_HOME con el

comando echo $JAVA_HOME, como se observa en la figura 5.11.
echo $JAVA_HOME
Figura 5.11
5.2.3 Instalación de Maven

Maven es una herramienta de software libre que simplifica los procesos de compilar
y generar ejecutables desde el código fuente. Con esta herramienta ya no debe
haber preocupación de los detalles de cada nuevo proyecto; por ejemplo, ya no es
necesario analizar qué parte de un código se debe compilar o que librerías
considerar, entre otros.
El objetivo principal de Maven es permitir que un desarrollador comprenda el estado
completo de un esfuerzo de desarrollo en el menor tiempo posible. Para lograr este
objetivo, Maven facilita el proceso de construcción, proporciona un sistema de
construcción uniforme, proporciona información de proyectos de calidad y fomenta
mejores prácticas de desarrollo [Maven].
Observar que Maven requiere que JDK esté instalado. Para iniciar con la instalación
de Maven se debe ingresar el comando sudo apt update, como se observa en la
figura 5.12.
sudo apt update
Figura 5.12
Para instalar Maven se debe ingresar el comando sudo apt install maven, como
sudo apt install maven
Figura 5.13
Para conocer la versión de Maven, se debe ingresar el comando mvn -versión,

como se observa en la figura 5.14, donde se indica la versión de Maven y de Java.
mvn -version
Figura 5.14
5.2.4 Instalación de Apache Karaf 3.0.5

Karaf es un contenedor OSGi de código abierto de propiedad de Apache; OSGi
(Open Service Gateway initiative) es un conjunto de estándares donde se da
especificaciones abiertas de software para el diseño de plataformas que ofrezcan
múltiples servicios. Karaf es uno de los componentes que se necesita para instalar
ONOS.
Para continuar con la instalación ordenada, se debe crear en el directorio onos

donde se descargará posteriormente el archivo apache-karf-3.0.5; como se observa
en la figura 5.15.
mkdir onos
ls
cd onos
Figura 5.15
Para instalar apache-karf-3.0.5 se debe de ingresar el comando sudo wget

https://archive.apache.org/dist/karaf/3.0.5/apache-karaf-3.0.5-src.tar.gz, como
se observa en la figura 5.16. wget es una herramienta informática para la descarga
de contenidos y archivos desde servidores web. El nombre wget se genera de la
combinación world wide web y la palabra get.
sudo wget https://archive.apache.org/dist/karaf/3.0.5/apache-karaf-3.0.5-src.tar.gz
Figura 5.16
Con el comando ls se verifica que el archivo apache-karaf-3.0.5-src.tar.gz está en

el directorio onos, como se observa en la figura 5.17.
ls
Figura 5.17
Se descomprimirá este archivo con el comando tar -zxvf apache-karaf-3.0.5-

src.tar.gz, como se observa en la figura 5.18.
tar -zxvf apache-karaf-3.0.5-src.tar.gz
Figura 5.18
Producto de la descompresión se crea un directorio apache-karaf-3.0.5. Con el

comando ls de visualiza este directorio como se observa en la figura 5.19.
ls
Figura 5.19
Puppet Labs mantiene repositorios de paquetes oficiales para varias de las

distribuciones de Linux más populares. Nuevamente ingresar al directorio
Descargas y desde allí ingresar el siguiente comando sudo wget
http://apt.puppetlabs.com/puppetlabs-release-precise.deb como se observa en
la figura 5.20.
cd ..
cd Descargas
sudo wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb
Figura 5.20
Ahora se debe observar que en el directorio Descargas contiene el archivo

descargado puppetlabs-release-precise.deb como se observa en la figura 5.21.
Figura 5.21
El programa dpkg es la base para manejar paquetes Debian en el sistema [Debian].

Si se dispone de paquetes .deb, el programa dpkg permite instalar o analizar sus
contenidos, proporcionando información sobre los paquetes. Pero este programa
sólo tiene una visión parcial del universo Debian: sabe lo que está instalado en el
sistema y lo que sea que se le provee en la línea de órdenes, pero no sabe nada
más de otros paquetes disponibles.
Para instalar un archivo .deb se debe ingresar el comando sudo dpkg -i

nombre_archivo.deb; en este caso, para instalar el archivo puppetlabs-release-
precise.deb se debe ingresar el comando sudo dpkg -i puppetlabs-release-
precise.deb, como se observa en la figura 5.22.
sudo dpkg -i puppetlabs-release-precise.deb
Figura 5.22
Se finaliza esta etapa de configuración ingresando el comando indicado en la figura

5.23.
sudo apt-get install gcc g++ make libpcre3-dev libssl-dev tmux emacs libncurses5-dev libreadline-dev
libffi-dev libyaml-dev valgrind git-core libxml2-dev libxslt-dev ntp sqlite3 libsqlite3-dev
Figura 5.23
5.2.5 Instalación del repositorio git-core

Git es un sistema de control de versiones distribuido, permite que cualquier
desarrollador tenga acceso a su código fuente y su historial de cambios para
mejorarlo utilizando los comandos de Git. GitHub es el host individual más grande
para los repositorios de Git y es el punto central de colaboración de millones de
desarrolladores y proyectos (pag. 167 del libro Pro Git). Amplia información del
repositorio Git en: https://github.com/progit/progit2/releases/download/2.1.349/progit.pdf.
Para instalar en el Ubuntu el acceso al repositorio Git ingresar el comando sudo
apt-get install git-core. Desde el directorio onos se realizará la instalación como
cd ..
cd onos
sudo apt-get install git-core
Figura 5.24
Por otro lado, la herramienta net-tools facilita el control del subsistema de red del
kernel de Linux; incluye arp, ifconfig, netstat, rarp, nameif, route y aspectos
avanzados de configuración de IP (iptunnel, ipmaddr). El comando sudo apt-get
install net-tools habilita esta herramienta como se observa en la figura 5.25.
sudo apt-get install net-tools
Figura 5.25
5.2.6 Descarga del controlador ONOS

En la siguiente página web se tiene las diversas versiones del controlador Onos:
https://wiki.onosproject.org/display/ONOS/downloads, como se observa en la figura
5.26.
Figura 5.26
Al seleccionar la versión 2.7.0 se accede a la siguiente dirección web:

https://repo1.maven.org/maven2/org/onosproject/onos-releases/2.7.0/onos-2.7.0.tar.gz .
Amplia información de esta versión en https://api.onosproject.org/2.7.0/apidocs/ . En la
figura 5.27 se observa el comando que se ingresa desde el terminal de Ubuntu para
descargar onos versión 2.7.0,
sudo wget https://repo1.maven.org/maven2/org/onosproject/onos-releases/2.7.0/onos-2.7.0.tar.gz
Figura 5.27
Ahora se tiene en el directorio de trabajo, onos, el archivo comprimido onos-

2.7.0.tar.gz, como se observa en la figura 5.28.
Figura 5.28
A continuación, se descomprime el archivo onos-2.7.0.tar.gz con el comando tar -

zxvf onos-2.7.0.tar.gz, como se observa en la figura 5.29.
tar -zxvf onos-2.7.0.tar.gz
Figura 5.29
Al finalizar el proceso de descomprimir se tiene el directorio onos-2.7.0, como se

observa en la figura 5.30.
Figura 5.30
A continuación, se debe ingresar al directorio onos-2.7.0 y luego al directorio bin.

Ubicado en este directorio, observar su contenido con el comando ls y notar el
archivo onos-user-password que es donde se define el usuario y password para
el acceso a la aplicación de gestión del controlador onos; como se observa en la
figura 5.31.
cd onos-2.7.0
cd bin
ls
Figura 5.31
Para definir el usuario y password para el acceso a la aplicación de gestión del

controlador onos se debe ejecutar el archivo onos-user-password con el comando
sudo ./onos-user-password onos onos, definiendo para la aplicación como
usuario onos y password onos, como se observa en la figura 5.32.
sudo ./onos-user-password onos onos
Figura 5.32
Se configuró el controlador Onos: usuario → onos password → onos

Para lanzar el controlador Onos se debe ingresar el comando sudo ./onos-

service start, como se observa en la figura 5.33.
sudo ./onos-service start
Figura 5.33
El indicativo que todo está correcto es el mensaje que aparece en la última línea:
Update nodo 10.0.2.15 state to READY, como se observa en la figura 5.34.
Figura 5.34
La dirección IP 10.0.2.15 que se observa en la última línea corresponde a la

dirección IP de la máquina virtual que contiene el controlador Onos. Desde un
terminal de Ubuntu ingresar el comando ifconfig (ó el comando ip a) para observar
los parámetros de la máquina virtual (10.0.2.15), como se observa en la figura 5.35.
ifconfig
Figura 5.35
5.2.7 Aplicación gráfica del controlador ONOS

Para lanzar la aplicación del controlador Onos que muestra todos los detalles de la
red SDN se debe activar como cliente desde el Firefox e ingresar como dirección
web: localhost:8181/onos/ui/index.html, como se observa en la figura 5.36.
El usuario → onos y password → onos
Figura 5.36
Mostrando una interfaz gráfica donde se mostrará todos los detalles de la red SDN
a simular, como se observa en la figura 5.37.
Figura 5.37
5.2.8 Instalación de las aplicaciones en ONOS

El controlador Onos tiene previamente instalado las aplicaciones: Default Drivers
y ONOS GUI2 ; siendo necesario activar otras.
Para analizar las aplicaciones instaladas pulsar el ícono ubicado en la parte superior
izquierda y luego Aplicaciones , como se observa en la figura 5.38.
Figura 5.38
Por ejemplo, si se desea activar la aplicación DHCP Server: ,

seleccionar esta aplicación y luego pulsar el ícono ubicado en la parte superior
derecha de la interfaz gráfica de la plataforma Onos, como se observa en la figura
5.39.
Figura 5.39
El proceso de selección finaliza cuando se confirma la acción pulsando la opción OK

que aparece en la ventana emergente, como se observa en la figura 5.40.
Figura 5.40
Se recomienda que todas las aplicaciones relacionadas con el protocolo OpenFlow

estén activadas. En el recuadro de búsqueda, al ingresar openflow se obtendrá una
lista de todas las aplicaciones vinculadas a OpenFlow como se observa en la figura
5.41; a continuación, se debe activar cada una de ellas.
Figura 5.41
En la figura 5.42 se muestra todas las aplicaciones activadas en el controlador Onos.

Figura 5.42
Reactive Forwarding (fwd): Proporciona tráfico entre host finales utilizando

programación de flujos hop-by-hop, interceptando paquetes para los cuales no hay
objetivos de flujo en el plano de datos. Las rutas encontradas de esta forma tienen
un período de vida corto, i.e. expiran pocos segundos después de que el flujo en el
que estaban programadas se detiene. La aplicación relega en el servicio de rutas de
ONOS para computar las rutas más cortas. En el caso de eventos de topología
negativos (pérdida de enlaces, desconexión de dispositivos, etc.), la aplicación
invalidará cualquier ruta cuya programación delegue en algún recurso que ya no
esté disponible.
Topology &IntentMetrics (metrics): Aplicación para la monitorización de métricas
relacionadas con cambios de topología y programación de intents.
Control Plane Manager (cpman): Aplicación para la monitorización de la salud del
cluster de ONOS.
Packet Statistics (packet-stats): Aplicación para calcular el número de paquetes
de cada tipo.
Openflow: Conjunto de aplicaciones englobadas bajo este nombre las cuales
activan el protocolo Openflow.
5.3 SIMULACIÓN DE UNA RED SDN CON EL CONTROLADOR ONOS

5.3.1 Red con MiniEdit
La red definida por software con el controlador Onos realizado con el MiniEdit se
muestra en la figura 5.43.
Figura 5.43
Los valores seleccionados al seleccionar Edit y Preference está indicado en la

figura 5.44a y en el controlador co es indicada en la figura 5.44b.
Figura 5.44a Figura 5.44b
Luego se debe correr la red simulada en MiniEdit pulsando la opción Run ubicado
en la parte inferior izquierda, como se muestra en la figura 5.45.
Figura 5.45
Desde el terminal del Mininet se comprueba conexión entre todos los hosts de la
red con el comando pingall, como se muestra en la figura 5.46.
Figura 5.46
5.3.2 Visualización de la red desde la interfaz gráfica del controlador ONOS

Para obtener la topología pulsar el ícono ubicado en la parte superior izquierda
y luego Topología , como se observa en la figura 5.47.
Figura 5.47
En la figura 5.48 se muestra la topología simulada defina en el MiniEdit.
✓ Verifique la conectividad entre todos los hosts con el comando pingall

✓ Para vidsualizar los hosts pulsar en simultaneo las teclas CONTROL y H.
Figura 5.48
5.4 ACCESO AL ONOS CON CLI

Para acceder a la interfaz de línea de comandos-CLI del controlador Onos se debe
activar un nuevo terminal del Ubuntu e ingresar el comando ssh -p 8101
onos@localhost; donde onos es el password de ingreso que se definió en el
proceso de configuración del controlador Onos. Ante el pedido de tipear “yes”
ingrese completo “yes”, como se observa en la figura 5.49.
ssh -p 8181 onos@localhost
Figura 5.49
5.5 RESUMEN DE CONFIGURACIÓN DEL CONTROLADOR ONOS

Actualización del Ubuntu
========================
sudo apt-get update
sudo apt-get upgrade
Instalación de JAVA JDK

=======================
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:linuxuprising/java
sudo apt-get update
java -version
-->Vericar que NO debe existir JAVA instalado
sudo apt install default-jdk
java -version
-->Vericar que SI debe existir JAVA instalado version 11
echo $JAVA_HOME
-->Vericar que NO está definido la variable JAVA_HOME instalado
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
echo $JAVA_HOME
-->Vericar que SI está definido la variable JAVA_HOME instalado
Instalación de Maven
====================
sudo apt update
sudo apt install maven
mvn -version
-->Ver la versión instalada
Instalación de Apache Karaf 3.0.5

=================================
mkdir onos
cd onos
sudo wget https://archive.apache.org/dist/karaf/3.0.5/apache-karaf-3.0.5-src.tar.gz
-->Verificar en el directorio onos la existencia del archivo apache-karaf-3.0.5-
src.tar.gz
tar -zxvf apache-karaf-3.0.5-src.tar.gz
-->Verificar en el directorio onos la existencia del archivo descomprimido
apache-karaf-3.0.5
Por buenas costumbres ir al directorio Descargas:
++++++++++++++++++++++++++++++++++++++++++++++++
sudo wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb
-->Verificar en el directorio onos la existencia del archivo puppetlabs-release-
precise.deb
sudo dpkg -i puppetlabs-release-precise.deb
sudo apt-get install gcc g++ make libpcre3-dev libssl-dev tmux emacs libncurses5-
dev libreadline-dev libffi-dev libyaml-dev valgrind git-core libxml2-dev libxslt-dev ntp
sqlite3 libsqlite3-dev
++++++++++++++++++++++++++++++++++++++++++++++++
Instalación del repositorio git-core
====================================
Desde el directorio onos:
sudo apt-get install git-core
sudo apt-get install net-tools
Instalación del controlador onos

================================
Desde el directorio onos:
sudo wget https://repo1.maven.org/maven2/org/onosproject/onos-
releases/2.7.0/onos-2.7.0.tar.gz
-->Puede seleccionar la versión onos-2.5.0.tar.gz
tar -zxvf onos-2.7.0.tar.gz

-->Verificar la presencia en el directorio onos el directorio onos-2.7.0
Ingresando al directorio onos-2.7.0 y al directorio bin (debe estar ubicado en
onos/onos-2.7.0/bin)
sudo ./onos-user-password onos onos
sudo ./onos-service start
Activar la aplicación de gestión del controlador onos

=====================================================
Activando el FireFox ingresar la dirección web: localhost:8181/onos/ui/index.html
(localhost:8181/onos/ui/login.html)
-->El user y password es onos (así se definió)
-->Debe activa una red SDN con el miniedit.
Acceso al controlador Onos con comando CLI
En un nuevo terminal de Ubuntu:

ssh -p 8101 onos@localhost → onos es el password creado al momento de
configurar Onos.
BIBLIOGRAFÍA
[Debian] Debian, “El manual del administrador de Debian”, https://debian-
handbook.info/browse/es-ES/stable/sect.manipulating-packages-with-dpkg.html
[Hogan-2020] B. Hogan-2020, “Cómo instalar Java con Apt en Ubuntu 20.04”,
https://www.digitalocean.com/community/tutorials/how-to-install-java-with-apt-on-
ubuntu-20-04-es
[Koshibe 2016] A. Koshibe and E. Olkhovskaya, “ONOS: An Overview.”
https://wiki.onosproject.org/display/ONOS/ONOS+ %3A+An+Overview
[Maven] Apache Maven Project, https://maven.apache.org/
[Koshibe] Koshibe, A., Installing and Running ONOS,
https://wiki.onosproject.org/display/ONOS15/Installing+and+Running+ONOS
[Koshibe 2017] A. Koshibe, Wiki de ONOS, “Administrator Guide - ONOS - Wiki
(onosproject.org)”, https://wiki.onosproject.org/display/ONOS/Administrator+Guide
[Youtube] Onos sdn controller Instalación. https://youtu.be/WZHfkMK1XUI
[Indermitte 2020] ONOS, https://wiki.onosproject.org/display/ONOS/

Libro de Simulación-Redes Definida Por Software Con Mininet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Libro de Simulación-Redes Definida Por Software Con Mininet

Uploaded by

Copyright:

Available Formats

Capítulo 1 REDES DEFINIDAS POR SOFTWARE: Marco teórico

Capítulo 1 REDES DEFINIDAS POR SOFTWARE: Marco teórico

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

Lima, 5 de setiembre 2022

Capítulo 1 Redes Definidas por Software: Marco teórico

Capítulo 2 Máquinas virtuales con Ubuntu y Mininet

Capítulo 3 Controlador Ryu

Capítulo 4 Controlador OpenDayLight

4.8 Inicio de OpenDayLight

Capítulo 5 Controlador ONOS

establecimiento de un servicio; o cuando el servicio está ofreciéndose el cliente

Figura 1.1 Capas e interfaces de la arquitectura SDN [Elaboración propia]

La Unión Internacional de Telecomunicaciones (ITU) en la recomendación ITU-

Interfaz northbound.- La Interfaz de Programación de Aplicaciones (API)

entre otras; impulsando la innovación o creatividad de los desarrolladores de

La Interfaz northbound debe promover la portabilidad de las aplicaciones; es decir,

En la figura 1.2 se muestra la interrelación de la capa de control con la capa de

Figura 1.2 Interfaces en SDN [Elaboración propia]

1.4 CONMUTADOR OPENFLOW

En la figura 1.3 se muestra la estructura interna del Conmutador. Todo Conmutador

Dentro del Conmutador existe un grupo de Tablas de Flujo interconectados en una

Figura 1.3 Modelo de un Conmutador [Elaboración propia]

Cuando unos datos ingresan al Conmutador, se analiza el cumplimiento de campos

En la especificación del protocolo OpenFlow detallado en ONF (2015) se explica

En la figura 1.5 se muestra de manera resumida el funcionamiento de un conmutador

Figura 1.5 funcionamiento de un conmutador SDN [Elaboración propia]

1.5 SISTEMA OPERATIVO DE LA RED DEFINIDAS POR SOFTWARE

Figura 1.6 Escenario para medir el rendimiento de controladores [Mamushiane et al (2018)]

Uno de los resultados de Mamushiane et al (2018) es la evaluación del rendimiento

pobre y permanece constante independientemente del número de conmutadores

Para ambos estudios es indispensable introducir nuevos escenarios de análisis que

Tabla 1.1 Comparación entre los principales controladores SDN [Adaptado

ITU-T.G.7702 (2018). Architecture for SDN control of transport networks.

Mamushiane, L., Lyko, A., Dlamini, S. (2018). A Comparative Evaluation of the

McKeown, N., Anderson, T., Balakrishnan, H. (2008). OpenFlow: Enabling Innovation in

ONF-2015-Open Networking Foundation. OpenFlow Switch Specification-v1.5.1.

Schaller, S., Hood, D., (2017). Software Defined Networking

Figura 2.1 Descarga del Ubuntu 20.04.4

Almacene la imagen ISO en su escritorio de trabajo, para la instalación posterior en

La imagen de la versión Ubuntu de escritorio permite probar el sistema operativo

Figura 2.2 Tipo de sistema de la PC con Windows

2.3 UBUNTU 20.04.4 EN VIRTUALBOX

Para instalar el Ubuntu 20.04.4 en VirtualBox se debe seleccionar Nueva desde

Figura 2.3 Nueva máquina virtual en VirtualBox

2.3.2 Selección del ISO del Ubuntu

Figura 2.5 Configurar el ISO del Ubuntu 20.04.4 en el VirtualBox

De la nueva ventana seleccionar “Almacenamiento” y la opción “Vacío”

2.3.3 Instalación del Ubuntu 20.04.4 en VirtualBox

En esta parte de la instalación ingrese su nombre, el nombre de la máquina virtual,

El proceso de instalación del ubuntu 20.04.4 finaliza inicializando la máquina virtual;

2.3.4 Ingreso al Ubuntu 20.04.4 en VirtualBox

2.3.5 Modo NAT del Ubuntu 20.04.4 en VirtualBox por defecto

2.3.6 Instalación de ifconfig en Ubuntu 20.04.4

Figura 2.12 ifconfig en ubuntu 20.04.4 no está instalado

sudo apt update

Figura 2.13 Actualización del ubuntu 20.04.4

Figura 2.14 Instalación de herramientas para ver las configuraciones de red

Nuevamente con el comando ifconfig se observará la interfaz (enp0s3) y su

Figura 2.15 Dirección IP de la interfaz de red

Observar que el comando ifconfig está siendo obsoleto y la tendencia es

Figura 2.16 Ubicación del comando ifconfig

2.4 INSTALACIÓN DEL MININET

2.4.2 Repositorio Git