Primera capacitación en sdn para el proyecto Bella-T

Redes Definidas por
Software (SDN)
Javier Richard Quinto A.
richardqa@gmail.com
jquinto@inictel-uni.edu.pe
INICTEL-UNI

Quien soy yo ?
- Magister en Ing. de la Computación.
- Investigador del INICTEL-UNI (10’)
- Forma parte del grupo de investigación
GIRA (PUCP) e INTRIG (UNICAMP)
- Lidero el proyecto: Nuevas tecnologías
en SDN/Openflow y P4, INICTEL-UNI
- Miembro del proyecto de despliegue y
documentación de nuevos servicios para
eduroam Latino América, RNP e
INICTEL-UNI
-Mis fortalezas: SDN, P4, NFV, Cloud,
Seguridad IPv4/IPv6, AAA/802.1x
@opennetsoft
fb.com/
opennetsoft
Sigueme en:

Agenda
08:00-08:45am Problemática y estrategias de
soluciones
08:45-09:15am Arquitecturas SDN y NFV
09:15-09:35am Modelos de SDN
09:35-10:00am Controladores SDN
10:00-10:30 Hands-on 1: Controladores
ODL, Ryu
10:30-10:50am BREAK
10:50-11:30am Interfaces SDN
11:30-12:30am Protocolo OpenFlow y su
evolución
12:30-1:00pm Hands-on 2: Mininet, O.F1.3 y
Open vSwitch
1:00-2:00pm Almuerzo
2:00-3:00pm Interface RESTFul y
Orquestadores SDN
3:00-4:00pm Hands-on 3: Open DayLight
y Postman
4:00-4:20pm BREAK
4:20-4:50pm Desafios Actuales: Machine
Learning, Load Balancing,
802.1X en SDN
4:40-5:10pm Proyectos de Investigación en
SDN

Problemática y Estrategias de
Solución en las Redes
Convencionales

Equipamiento de Redes Propietarias
Verticalmente integrado, complejo, cerrado y propietario!
Custom
Silicon
(ASIC)
Switches de
redes
Componentes
No recomendable para propietarios de redes ni para
usuarios

Problemáticas en las Redes Actuales
Source: Tutorial SDN & NFV LACNIC26 by Whitestack

Las redes como lo aprendiste en la
escuela
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN

Redes en la Práctica
Estado enlace
distribuido
Estado de
configuración estática
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN

Redes en la Práctica
Teoría y práctica son lo mismo, pero en la práctica son muy
diferentes!

Camino a la Evolución
Adapted from: Transforming the Network with OpenSDN by Big Switch Network

Source: Introduction to OpenFlow, SDN and NFV, Kingston Smiler

Custom
Silicon
Merchant
Silicon
Facebook

Cumulus Networks: Sistema Operativo de redes para switches del
tipo Bare Metal. Automatiza, opera y escala en tu negocio. Cumulus
no soporta OpenFlow

Existentes
- CLIs
- Código cerrado
- Proporcionado por el
proveedor
- Aplicaciones conocidas
Nuevas
- APIs
- Código abierto
- Proporcionado por el
cliente
- Funciones de Redes
Virtuales (NFV)
Adapted from: Kyle Mestery, Next Generation Network Developer Skills

La Tendencia en Computación
- Cambios en los
patrones de tráfico.
- El consumismo de IT
- El aumento de los
servicios en la nube
- Big Data significa
más ancho de banda

Rediseñar la Red!
Plano de Datos:
Streaming de paquetes
Forwarding, Filtros, Buffer, rate-limit,
measure packets
Source: Adapted from J. Rexford

Rediseñar la Red!
Plano de Control:
Algoritmos Distribuidos
Seguimientos en los cambios de la topología, rutas
computarizadas, instalación de nuevas reglas

Rediseñar la Red!
Recoger mediciones y configurar equipamientos
Plano de Gestión:
Escala de tiempo

Rediseñar la Red!
● Gestión más simple
No necesita invertir más en el plano de gestión
● Ritmo más rápido de inovación
Menos dependencia con los Vendors y Estándares
● Interoperabilidad más fácil
Compatibilidad solamente en los protocolos de cable
● Equipamientos más simple y más fácil
Más uso de software

Origen del Termino SDN
Source: http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/

Redes Definidas por Software (SDN)
Plano logicamente centralizado
API al Plano de Datos
(e.g., OpenFlow)
Inteligente
& Lento
Tonto &
Rápido

Source: https://www.opennetworking.com
Directamente Programable
Agilidad y Flexibilidad
Centralmente gestionado
Estándares abiertos y
neutral al vendor

Nuevas habilidades y
oportunidades
Herramientas
sofisticadas
Reduce CapEx/OpEx

Source: N. Mckeown et al.

Funciones de Redes Virtuales (NFV)
- Hardware commodity
Source: https://www.opennetworking.com , Network Function Virtualization: Perspectivas, Realidades e Desafios
- Ahorro en espacio y
energía
- Innovación más rápida
- Asignación flexible de
recursos
- Multiplicidad de usuarios
- Mayor rentabilidad

Sources: Ahmad Rostami, Ericsson Research (Kista):
http://www.itc26.org/fileadmin/ITC26_files/ITC26-Tutorial-Rostami.pdf and Uwe Michel, T-Systems
Flexibilidad y Programabilidad en la Red
(SDN & NFV)

Flexibilidad y Programabilidad en la Red
(SDN & NFV)

Open Networking
Source: Porqué los Tier-1 están adoptando las SDN y nFV?, whitestack

Certificaciones ONF: SDN/Openflow

Modelo: Open SDN
- Estándares abiertos
(openflow)
- Software de código abierto
(Openstack, Open DayLight)
- APIs y SDKs
- Hardware abierto (Open
compute project)

Modelo: SDN Hibrido
- Conviven con redes
tradicionales
- Soportan Openflow 1.3
- Más adecuado para
migraciones en SDN

Modelo: Overlay SDN
- Método de despliegue
para virtualización de
redes
- Ejecutado sobre una red
separada logicamente
- Big Switch Network y
Vmware usan overlay

Populares Controladores SDN OpenSource
Phyton
Phyton
Java Java
C/Ruby

Controladores SDN (Open Source y
Vendors)
a) Lista de los controladores SDN ofrecidos por los Vendors:
Brocade, Cisco, HPE, Juniper, NEC,and Nuage
https://www.sdxcentral.com/sdn/definitions/sdn-controllers/sdn-controllers-compre
hensive-list/
b) Lista de los controladores SDN Open Source: Open DayLight,
Ryu, Nox, Pox, ONOS
https://www.sdxcentral.com/sdn/definitions/sdn-controllers/open-source-sdn-contr
ollers/

Lista de Proyectos en Open DayLight

Open DayLight (Lithium)
➢ Java multiplataforma
➢ Interfaces Java: escucha eventos
(listening), especificaciones y forma
patrones
➢ Maven: construye sistemas para Java.
➢ OSGi: Permite cargar bundles
dinamicamente, registrar dependencias
y servicios exportados e intercambiar
información entre bundles.
➢ Karaf: Ligero runtime para cargar
modules/bundles. Basado en OSGi.

Hands-on 1:
Controladores ODL y
Ryu

Controlador Open DayLight
# Open DayLigth (https://www.opendaylight.org/downloads)
Acceder al directorio de trabajo de Open DayLight y ejecuta el controlador:
cd ~/distribution-karaf-0.4.4-Beryllium-SR4
sudo ./bin/karaf clean (debug es opcional)
opendaylight-user@root> feature:list (-i es opcional)
opendaylight-user@root> feature:install odl-dlux-core (instala UI)
opendaylight-user@root> feature:install odl-openflowplugin-all
opendaylight-user@root> feature:install odl-l2switch-switch
opendaylight-user@root> feature:install odl-restconf
opendaylight-user@root> feature:install odl-mdsal-apidocs
opendaylight-user@root> bundle:list |grep Active
Crearemos un escenario mininet indicando como controlador al ODL
$ sudo mn --mac --switch ovsk --controller remote
Conectando al cotrolador remoto en: 127.0.0.1:6653
is_connected: true

Una vez terminado de instalar todos los plugins de arriba, vamos
a conectarnos a los switches y a manejar los flujos entrantes.
Entrar:
a) http://<IP>:8181/index.html
p1- ¿Expliqué que cambios sucede cuando haces Ping entre H1 y H2?, y ¿Qué
feature permite dicha visualización?
b) http://<IP>:8181/restconf/operational/network-topology:network-topology/
p2- ¿Explica la información mostrada, y que feature permite acceder a esa
información?
c) http://<IP>:8181/apidoc/explorer/index.html
p3- ¿Explica la información mostrada, y que feature permite acceder a esa
información?

d) Ingrese una entrada de flujo usando CURL
Copie el contenido XML del siguiente enlace y grabalo como sample.xml:
https://github.com/richardqa/SDNLab/blob/master/XML/sample.xml
curl -u admin:admin -H 'Content-Type: application/yang.data+xml' -X PUT -d
@sample.xml
http://192.168.56.102:8181/restconf/config/opendaylight-inventory:nod
es/node/openflow:1/table/0/flow/1'
p4- ¿Que cambios observas en la tabla de flujo del switch OVS?
mininet> sh ovs-ofctl dump-flows s1

Controlador Ryu
Components:
Provides interface for
control and state and
generates events
Communicates using
message passing
Libraries:
Functions called by
components
Ex: OF-Config, Netflow,
sFlow,
Netconf, OVSDB

Controlador Ryu
El comando para iniciar el controlador “RYU” es ryu-manager. Por
defecto el controlador no carga ninguna aplicación SDN
cd /home/ubuntu/ryu
./bin/ryu-manager --verbose ryu/app/simple_switch_13.py
Creamos la topología Mininet. Para controladores remotos, por defeto
OpenFlow 1.3 es configurado
sudo mn --topo single,3 --mac --controller remote --switch ovsk
Listas los flujos almacenados en la tabla OVS
sudo ovs-ofctl dump-flows s1

Interfaces Northbound/Southbound
Interface Northbound: Interfaz
computacional para desarrolar
aplicaciones.Ésta interface abstrae
el conjunto de instrucciones
low-level usados por la interface
Southbound para programar
dispositivos de forwarding.
Interface Southbound: Define el
protocol de comunicación entre los
dispositivos de forwarding y los
elementos del plano de control.
Éste protocolo formaliza la manera
de como ambos planos (Control y
Datos) interactuan. Por Ejemplo:
Openflow, OVSDB, ForCES, POF,
sFlow, etc.

Interfaces Westbound/Eastbound
Westbound/Eastbound: Son interfaces especiales requeridas por los controladores
distribuidos. Los controladores actuales implementan su propio API westbound/eastbound.
Las funciones de éstas interfaces incluyen Importar/Exportar Data entre controladores,
algoritmos para el modelo de consitencia de datos, y capacidades de monitoreamiento y
notificaciones.
El estandar SDNi define requerimientos comunes para coordinar el establecimiento de
flujos e intercambio de información de alcanzabilidad entre múltiples dominios.

Protocolo OpenFlow y su Evolución

Historia de Openflow, ACM SIGCOMM2008
● Openflow se originó en
la Univ. de Stanford en
2008.
● Openflow spec. V1.0 fue
lanzado en dic. 2009.
● Desde sus inicios
Openflow es gestionado
por la ONF.

OpenFlow y SDN
Inteligencia de las redes es movida desde el Switch hacia
un controlador externo

Entradas de tabla de flujos
Source: https://www.sdxcentral.com/sdn/definitions/what-is-openflow/

A Quick Jump Into SDN
SDN no es OpenFlow
pero ...
OpenFlow si es SDN
The physical separation of the network control
plane from the forwarding plane, and where a
control plane controls several devices.
Definición según la ONF:

OpenFlow y SDN
Aquí es en donde Openflow
si encajaría sobre SDN
Beneficios de
Openflow
- Programabilidad
- Inteligencia
centralizada
- Abstracción

Versions OpenFlow
La más reciente versión de
OpenFlow es la 1.5.1
Cada nueva versión mejora el
protocolo y adiciona nuevas
características
Desafortunadamente los
dispositivos hardware con soporte
Openflow usan, en su mayoria, la
versión 1.0
Version Release
0.8.0 May, 5, 2008
0.8.1 May, 20, 2008
0.8.2 Oct, 17, 2008
0.8.9 Dec, 2, 2008
0.9.0 Jul, 20, 2009
1.0 Dec, 31, 2009
1.1 Feb, 28, 2011
1.2 Dec 2011
1.3 Jun, 25, 2012
1.3.1 Sep, 6. 2012
1.3.2 Apr, 25, 2013
1.4.0 Oct, 14, 2013
1.5.0 Dec, 19, 2014
1.5.1 Mar, 26, 2015

¿Qué versión usar?
1.0 vs 1.3
Los mismos conceptos
Forwarding basados en flujo.
Información acerca del control de eventos en la red y
modifcación del estado del equipamiento
Diferentes Capacidades
OpenFlow 1.3 tiene más características y cubre más aspectos que
faltan en OpenFlow 1.0
->Multiple Tables, Groups, Rate Limiting, Controller Role
OpenFlow 1.0 es más simple y más fácil de implementar que 1.3. La
mayor parte de los campos son opcionales. Removiendo éstas
características nosotros tendríamos casi la versión 1.0

Switch OpenFlow (Componentes
principales)
Group Table
Opciones adicionales para reenviar
paquetes Disponible desde OpenFlow 1.1
Flow Table
Lookup and forwarding
OpenFlow Channel Comunicación
entre el SW y el controlador
Meter Table
Mecanismo simple QoS.
Disponible desde OpenFlow 1.3

Tabla de Flujos
Contiene entrada de flujo
OpenFlow 1.0 Flow entry
OpenFlow 1.3 Flow entry
Analogía de la tabla de flujo vs la tabla de enrutamientoable analogy

Instrucciones OpenFlow 1.3
Meter
Apply-Actions
Clear-Actions
Write-Actions
Write-Metadata
Goto-Table

OpenFlow 1.0 vs OpenFlow 1.3
Acciones
Output
Drop
Set VLAN ID
Set VLAN priority
Strip VLAN header
Modify Ethernet, IPv4.
transport src/dst address
Enqueue
Output
Set-Queue
Drop
Group
Push-Tag/Pop-Tag
Set-Field
Change-TTL
OpenFlow 1.0 OpenFlow 1.3

Tabla: Group
Disponible desde OpenFlow 1.1
Groups permiten nuevas opciones de forwarding
Type Function
All Broadcast, Multicast
Select Algorithm chooses the bucket
Indirect Only one bucket
Fast Failover Executes first live bucket

Meter Table
Band Type Function
Drop Drop packets that exceed rate
DSCP Remark Remark the drop precedence
of the DSCP field in the IP
header of the packets that
exceed the band rate value
Mediciones y control de la tasa de paquetes que hace match
de las entradas de flujos asignados al meter id

Canal OpenFlow
Canal de comunicación entre el SW
openflow y el Controlador
Conexión encriptada: TCP or TLS
IANA ha asignado un puerto para
la conexión entre OpenFlow
Switch-Controller: 6653

Handshake
Switch Controller
Hello Message
Después de establecer la conexión del TCP/TLS, ambos lados envian
mensajes “Hello Message”
Solves the OpenFlow
version
Solves the Hello. If
the version is not
supported sends an
Error message
Features Request
Features Reply
OpenFlow Connection
Established

Tipos de Mensajes
Controller-to-Switch
Asynchronous
Enviado por el switch sin
requerimiento del controlador
Symmetric
Enviado sin solicitación
por ambos lados
Controller
Flow-ModInicializado por el controlador.
Podría requerir, o no, una
respuesta del switch
Controller
Packet-In
Controller
Echo Request
Echo Reply

Controlador OpenFlow
Éste es en donde la inteligencia de
la red red es localizada. Switches
puro Openflow sin un controlador
son switches tontos.
OpenFlow
I want to talk with
the Desktop!

OpenFlow
Oh God! What
I’m gonna do?

OpenFlow
THE almighty
OpenFlow Controller
OpenFlow Channel
I’m here for you! Take
the power of the
Learning Switch!

Principales diseños de un
controlador
Que sean capaces de ejecutar y detener aplicaciones
durante el tiempo de ejecución del controlador
Que se espera de los controladores?
Mejorar la productividad del desarrollador. El
controlador API debería ser fácil de usar y optimizar
el tiempo gastado en desarrollar una aplicación
Realizar un buen trabajo para el escenario en donde
éste ha sido diseñado

Flujos Proactivo vs Reactivo
Reactive
Los flujos que no hacen “match” son enviados al controlador,
que instala los flujos basados sobre los campos del paquete. El
paquete es enviado de vuelta al switch para su debido
procesamiento.
Application Example: Learning Switch
Proactive
El controlador instala los flujos antes que el tráfico de
paquetes. Éste modelo es usado cuando nosotros ya
conocemos el tráfico que nosotros queremos manejar.
Application Example: Packet Monitor

Arquitectura en Controladores
Centralized Distributed

Casos de Uso (Open Source)
1. 6.4% de todo el tráfico
del Internet (ATLAS, 2010)
2. Google tien dos
grandes redes backbones:
Internet facing (user traffic)
Datacenter Traffic (Internal)
3. Google WAN usa
aplicaciones intensivas:
Youtube, Websearch, Google+,
Hangouts, Maps, AppEngine,
Android and Chrome updates.

Casos de uso (Laboratorio full Open
Source)

Future Internet Brazilian
Environment for Experimentation

Problematica de OpenFlow
Configuración Run-Time

Capa Independiente del Protocolo

Lo nuevo: Programación en Plano
de Datos (P4)

Hands-on 2:
Mininet con
Openflow1.3 y OVS

Herramientas instaladas en Ubuntu
Mininet (version 2.3)
Será usado para simular los switches, hosts y enlaces de la red
Open vSwitch (version 2.5)
Switch virtual Open vSwitch usado por mininet.
Ofsoftswitch13
CPqD y Ericsson OpenFlow 1.3 software switch, basado sobre el switch de
referencia de Stanford
Ryu controller
Ryu y OpenDayLight son uno de nuestros controladores elegidos
debido a su soporte a OpenFlow 1.0 y OpenFlow 1.3

Mininet
Mininet iniciará casi todo lo que necesitas. Mininet emularía
una completa red de hosts, enlaces, y switches sobre una
simple maquina. Para crear un ejemplo de dos hosts, una red
con un switch, solo sería ejecutar: ‘sudo mn’ .
Switch S1
Host H1 Host H2
Eth0 Eth1
Eth0 Eth1

Mininet con switch “ovsk”
El controlador de referencia local (ref) usa OpenFlow 1.0 por defecto. Para
usar OpenFlow 1.3, es necesario indicarlo con el siguiente parámetro:
“protocols=OpenFlow13”. For example:
$ sudo mn --mac --switch ovsk,protocols=OpenFlow13 --controller ref
mininet> dpctl show -O OpenFlow13
mininet> dpctl dump-flows -O OpenFlow13
mininet> h1 ping -c 3 h2 …..(x1)
Adding static rules using dpctl
mininet> dpctl add-flow "in_port=1,actions=output:2" -O OpenFlow13
mininet> dpctl add-flow "in_port=2,actions=output:1" -O OpenFlow13
mininet > h1 ping -c 3 h2 ….. (x2)
mininet > iperf h1 h2
p5- ¿Explica lo sucedido en x2 y x1?
p6- ¿Cual es el valor que muestra el Iperf entre h1 y h2?

Mininet con switch “ovsk”
Ovs-ofctl es la herramienta utilitaria para el monitoreo y
administración de switches Openflow.
Capacidad del Switch OpenFlow
mininet> sh ovs-ofctl show s1 -O OpenFlow13
Descripción del Switch OpenFlow
mininet> sh ovs-ofctl dump-desc s1 -O OpenFlow13
Mecanismo para adicionar flujos Openflow
mininet> sh ovs-ofctl -O OpenFlow13 add-flow s1
priority=100,in_port=1,actions=output:2
Medir las Estadísticas de flujos en switches OpenFlow
mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13
Estadísticas de puertos de los switches OpenFlow
mininet> sh ovs-ofctl dump-ports s1 -O OpenFlow13

Mininet con switch “user”
Primero, cerremos nuestra topología mininet actual: $ mn -c
El switch software OpenFlow 1.3 tiene una similar herramienta al
ovs-ofctl: “sudo mn --switch user --controller ref”
Capacidades del switch
$ mininet> sh dpctl unix:/tmp/s1 features
Descripción del switch
$ mininet> sh dpctl unix:/tmp/s1 stats-desc
Adicionar flujos
$ mininet> sh dpctl unix:/tmp/s1 flow-mod cmd=add,table=0 in_port=1
apply:output=2
$ mininet> sh dpctl unix:/tmp/s1 flow-mod cmd=add,table=0 in_port=2
apply:output=1
Estado de la tabla de flujos
$ mininet> sh dpctl unix:/tmp/s1 stats-flow

Mininet con switch “user”
$ mininet> iperf h1 h2
p7- ¿Cual es el valor que muestra el Iperf entre h1 y h2?
p8- ¿Explique porqué las diferencias en los resultados del Iperf
obtenido en p6) y p7) ?
● Note que en el primer caso se consigue un BW en Iperf TCP mucho
menor que comparado en el segundo caso usando el switch kernel

RESTFul y CURL
Creando una entrada OpenFlow del tipo Drop
curl -u admin:admin -H 'Content-type: application/json' -X PUT -d '{"installInHw":"true", "name":"flow4", "node":
{"id":"00:00:fa:0c:cf:b3:56:42", "type":"OF"}, "ingressPort":"7", "etherType": "0x800", "protocol": "6", "tpDst":
"80","nwSrc":"11.1.1.6","nwDst":"11.1.1.7", "priority":"65535","actions":["DROP"]}'
'http://11.1.1.5:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:fa:0c:cf:b3:56:42/staticFlow/sampl
eflow
Consultando un flujo determindo
curl -u admin:admin -H 'Accept: application/xml'
'http://IP:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:fa:0c:cf:b3:56:42/staticFlow/sampleflow’'
Eliminando un flujo determinado
curl -u admin:admin -X DELETE
'http://IP:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:fa:0c:cf:b3:56:42/staticFlow/sampleflow’
Adicionando un Bridge
curl -u admin:admin -H 'Content-Type: application/json' -X POST
http://IP:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/HOST1/br1

Hands-on 3:
Uso de Open
DayLight y Postman

Directorio Principal de Trabajo: /home/tutorial/SDNLab
Este directorio puedes descargarlo desde mi GIT:
git clone https://github.com/richardqa/SDNLab.git
Abra una terminal (Ctrl-Shift-T) y accede al directorio de trabajo
SDNHub_Opendaylight_Tutorial en donde se tienen incluidas las
aplicaciones ejemplos para éste tutorial
1) a Hub / L2 learning switch
2) a network traffic monitoring tap.
Setup

Para un mejor entendimiento de éste tutorial, hemos creado las siguientes
variables de entorno. Ver el archivo ~/.bashrc
a) Ir al directorio del controlador:
export control=~/SDNLab/distribution/opendaylight-karaf/target/assembly/bin/
b) Ir al código del “Learning-Switch” y “tap aplication” respectivamente:
export
learn=~/SDNLab/learning-switch/implementation/src/main/java/org/sdnhub/odl/tutorial/learnings
witch/impl/
export
tapapp=~/SDNLab/tapapp/implementation/src/main/java/org/sdnhub/odl/tutorial/tapapp/impl/
c) Ir al directorio “Deploy”:
export deploy=~/SDNLab/distribution/opendaylight-karaf/target/assembly/deploy
d) Ir al directorio “Target” del programa:
export target1=~/SDNLab/learning-switch/implementation/target
export target2=~/SDNLab/tapapp/implementation/target (corregir en la VM)
e) Ir al directorio de trabajo “Learning Switch”:
export program1=~/SDNLab/learning-switch
f) Ir al directorio de trabajo “Tap”:
export program2=~/SDNLab/tapapp
Setup

Requisitos: JDK 1.8 and Apache Maven 3.3.9.
Los siguientes comandos permiten construir Maven e instalar todos los
componentes del controlador:
$ cd ~/SDNHub_Opendaylight_Tutorial/ # Ir al directorio de trabajo
$ mvn clean install # Limpiar cualquier cambio en la confguración del
código, e instalar de nuevo (Solo hacer una vez!)
$ cd $control # Ir a la ruta del controlador Open DayLight
$ ./karaf debug # Iniciar el controlador
karaf> feature:install sdnhub-XYZ # Instalar cualquier programa
disponible en el controlador
Como Construir ODL (No haga esto por
ahora!)

● pom.xml: El POM en el directorio principal especifica todos los
sub POMs a construir.
● commons/parent: Contiene el parent pom.xml con todas las
propiedades definidas para los sub proyectos.
● commons/utils: Contiene todas las utilidades personalizadas,
construidas para programar en Openflow.
● learning-switch: Contiene la aplicación L2 hub / switch
● tapapp: Contiene la aplicación monitoring tap application
● features: Define las dos características:
"sdnhub-tutorial-learning-switch", "sdnhub-tutorial-tapapp"
que puede ser cargadas en Karaf
● distribution/karaf-branding: Contiene Karaf para SDN Hub
● distribution/opendaylight-karaf: Contiene el empaquetamiento de
los POMs relevantes para generar un directorio en ejecución.
Organización del directorio

Maven y construcción del proyecto
Empecemos construyendo el proyecto principal:
~/SDNLab$ mvn clean install (Haga esto!)
Si al final de la instalación aparece el mensaje “BUILD SUCCESS”, significa
que la construcción fue exitosa. De otra manera, la construcción se
detendrá en el módulo donde fue encontrado el error.
Maven compila el código basado en el archivo pom.xml del directorio.
“install” es esencial para la compilación. Éste también acepta un argumento
opcional “clean” en el caso que se desea limpiar los archivos construidos
por maven.
Configuración del Maven

Now that we compiled our sample project, let’s run the controller itself;
preferably in a different terminal. (<CTRL>+<SHIFT>+T)
cd $control
./karaf debug
Parámetros del Karaf:
- Listar features disponibles en ODL
feature:list # Listar todos los features disponible en ODL
feature:list | grep sdnhub # Filtrar un feature específico en ODL
- Listar bundles disponibles en ODL
bundle:list -s | grep sdnhub # Filtrar un bundle específico en ODL
- Instalar nuestra feature “sdnhub-tutorial-learning-switch”
feature:install sdnhub-tutorial-learning-switch
Configuración del Karaf (No haga esto por
ahora!)

Configuración del Karaf (No haga esto por
ahora!)

El objetivo de éste ejercicio es convertir el “Hub Learning Switch” a un “Switch
de aprendizaje de MACs” que programa flujos.
1. Iniciar el controlador ODL en modo debug # Terminal 1
cd $control
./karaf clean
2. Verificar si el feature “sdnhub-tutorial-learning-switch” esta instalado
> feature:list -i |grep sdnhub-tutorial-learning-switch
Si éste feature no esta instalado, instala eso:
> feature:install sdnhub-tutorial-learning-switch
Espera 30 segundos hasta que el programa Learning-Switch este
instalado y activo
> bundle:list -s |grep learning-switch
189 | Active | 80 | 1.0.0.SNAPSHOT org.sdnhub.odl.tutorial.learning-switch.impl
Ejercicio 1: Configurando Learning-Switch

3. Iniciamos Mininet # Cambiar a un segundo terminal (#Terminal 2)
sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
* Esperemos a que el Controlador éste conectado al switch del mininet:
mininet> sh ovs-vsctl show
is_connected: true
4. Intentemos hacer Ping entre “host1” y “host2”
mininet> h1 ping h2
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
¿Porqué el Ping esta fallando?
5. Adicionamos la siguiente regla y nuevamente ejecutamos el Ping entre h1,h2
mininet> s1 ovs-ofctl add-flow tcp:127.0.0.1:6654 -OOpenFlow13
priority=1,action=output:controller
mininet> h1 ping -c 10 h2
Configuraciones Iniciales

6. Abrir y editar el archivo programa learning-switch # Terminal 3
vim $learn/TutorialL2Forwarding.java
private String function = "hub"; # Line 79
to
private String function = "switch";
Poner atención en las lineas #79 y #143. En la línea #79 se puede notar que la
función por defecto del código esta en modo “hub”. Esto significa que nuestro
programa learning-switch actuaría como Hub, por tanto el Ping entre Hosts
tendría un RTT alto.
7. En la linea #143 podríamos notar que el bloque de código relacionado al
comportamiento del programa learning-switch esta careciendo de lógica.
Completemos el código!. La respuesta esta en
$learn/TutorialL2Forwarding.single_switch.solution
Setup Configuration

8. Actualiza Maven desde la Ruta del programa, luego copia el JAR generado
por el Maven a la carpeta deploy de nuestro controlador
cd $program1 # Localización del programa “learning-switch”
mvn install -nsu
cp $target/learning-switch-impl-1.0.0-SNAPSHOT.jar $deploy/
9. Reinicializar el “controller” y nuevamente hacer Ping entre H1 y H2:
> logout # Logout to the controller
./karaf debug # Start the controller again
10. Esperar a que el switch nuevamente este conectado al controlador
(posiblemente 60 segundos), luego hacer Ping entre ambos Hosts.
mininet > h1 ping -c 5 h2
p9- ¿Notas algún cambio en la RTT obtenido en los pasos 5 y 9?
Setup Configuration

Wireshark
Desde otra terminal, inicie Wireshark y escoja la interface “loopback”.
Escoja el tipo de filtro: “openflow_v4”

El objetivo de éste ejercicio es usar RESTconf para enviar flujos estáticos al
Controlador. La entrada del REST esta basada en el modelo YANG. Por ejemplo,
en la figura debajo se muestra dos ejemplos de flujos estáticos usando tags XML.
Ejercicio 2: Programando Flujos usando REST

1. Inicializar el controlador ODL (Terminal #1)
cd $control
./karaf clean # Limpiar features y bundles (no es necesario hacer esto)
Instalar los features necesarios para usar Restconf
> feature:install odl-restconf odl-mdsal-apidocs odl-dlux-core
2. Inicializar la topología Mininet (Terminal #2)
sudo mn -c # Limpiar la anterior configuración mininet
sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
3. Dos archivos XML, “forward.xml” y “reverse.xml”, son almacenados en el
directorio ~/XML. Mediante el uso de la aplicación Postman crearemos dos
aplicaciones REST que envie flujos estáticos al controlador. Ver los siguients
pasos:

4. Abre la aplicación Postman y digite Request URL en PUT mode y configure
los parámetros headers necesarios:

5. Configuramos XML para forward ping (Ver ~/XML/forward.xml). Note que la
información XML es añadida al tag “Body”

6. Configuramos XML para reverse ping (Ver ~/XML/reverse.xml). Note que la
información XML es añadida al tag “Body”

7. Dump flujos desde mininet (terminal #2)
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=5264.052s, table=0, n_packets=20, n_bytes=1624, in_port=1 actions=output:2
cookie=0x0, duration=4983.190s, table=0, n_packets=17, n_bytes=1498, in_port=2 actions=output:1
8. Testing de conectividad entre hosts y and h2
mininet> h1 ping -c 3 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.432 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.118 ms
p10- ¿Mediante el uso de Postman modo Delate, como puedes borrar
las entradas de flujos creadas en los pasosNotas algún cambio en la
RTT obtenido en los pasos 5 y 6? (Ver el archivo ~XML/delete.xml)

La aplicación TAP para el monitoreo de tráfico es un simple programa de flujos
proactivos que organiza la fuente y los tipos de tráfico. Siguiendo los pasos del
tutorial nosotros podriamos construir ésta aplicación:
1. Extraer los detalles de la cabecera (header) del objeto TAP durante el
manejador de evento onDataChanged()
2. Para cada source-port, realizar los siguientes pasos para crear un flujo
- Creaar el objeto match usando los constructores apropiados match object using
appropriate builders
- Crear la lista de aóccin con las listas de acciones especificando el output to
sink-port
- Crear el objeto de flujo con el match y la lista de acción. Escribir éste objeto de
flujo a la tabla del flujo del nodo.
Note que el tipo de tráfico es un campo “enum” definido en el modelo YANG para
permitir que un usuario especifique los tipos de tráfico importantes digno de ser
monitoreados, tales como ARP, ICMP, DNS, DHCP, TCP, UDP.
Ejercicio 3: Monitoreando Tráfico de la red
usando TAP

Karaf Parameters:
- Instale los siguientes features necesarios para usar Restconf
feature:install odl-restconf-all
- Lista de programas instalados en Karaf
feature:list -i |grep odl-restconf-all
feature:list -i |grep tapapp
- Lista de bundles disponibles en ODL
bundle:list -s | grep sdnhub
Configuración Karaf

1. Inicializamos el controlador nuevamente
$ ./karaf debug
2. Iniciamos mininet
$ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13
--controller remote
Una vez que adiciones el modelo, puedes construir el proyecto y ejecutar
Karaf para inmediatamente verificar si tu modelo es suficiente para tu
aplicación. Por ejemplo, cuando ejecutamos Karaf, inclusive sin alguna
implementación o manejador de evento definido, podrías ser capaz de
almacenar data en el almacen de datos
Verificar que el código TapAPP Application este correctamente programada:
$tapapp/TutorialTapProvider.java
La solución se encuentra en:
$tapapp/TutorialTapProvider.unidirectional.solution (ojo: Reiniciar mvn)
usando TAP

3. Adicionemos flujos usando RESTFul. Abrimos una terminal en la VM y
copiamos la información siguiente:
$ curl -u admin:admin -H "Content-Type:application/json" -X PUT -d '{"tap-spec":
{"tap":[
{"id":"1",
"node":"openflow:1",
"traffic-match":"HTTP",
"src-node-connector":["openflow:1:1"],
"sink-node-connector":["openflow:1:2"]
}
]
}
}' http://localhost:8181/restconf/config/tap:tap-spec
usando TAP
Par verificar, podrías abrir el browser e inspeccionar la data en
http://localhost:8181/restconf/config/tap:tap-spec

4. Abrimos Postman e importamos el archivo XML almacenado en la ruta:
~/XML/tap.xml
usando TAP
En cada Tag adiconado se debería configurar Authorization Type como
“Basic Auth” and then click in “Update Request”

p11- Usando Postman, podríamos también adicionar dos diferentes
reglas para hacer matching entre ARP y ACMP?
p12- Que pasa si el controlador se apaga, los flujos son removidos?
5. Usando Postman, instalamos dos reglas (Tap1 addition y Tap2 addition)
sobre OVS, clicking en el boton “Send”.
6. Inspeccionamos la data almacenada:
http://127.0.0.1:8181/restconf/config/tap:tap-spec
7. Ahora, instalamos dos reglas deletion cliqueando en el boton “Send”.
Repetimos el paso 6.
8. Ahora, enviamos las dos reglas Create dummy. Ir al mininet y tipeamos lo
siguiente:
mininet> h1 ping h2
9. Finalmente, borramos estos flujos usando reglas Delete dummy
usando TAP

Agenda
soluciones
ODL, Ryu
10:30-10:50am BREAK
evolución
Open vSwitch
Orquestadores SDN
y Postman
4:00-4:20pm BREAK
Learning, Traffic Engineering,
Seguridad
SDN

Ingeniería de Tráfico
Adapted from: A roadmap for traffic engineering in SDN-Openflow Networks

Balanceamiento de Carga IDS &
Science DMZ
Fuente: A roadmap for traffic engineering in SDN-Openflow Networks

Seguridad en SDN
1. En la Capa Plano de Datos
2. En la Capa del Controlador
3. En la Capa SDN
Fuente:
http://www.networkworld.com/article/2840273/sdn/sdn-security-attack-vectors-and-sdn-hardening.html

Agenda
soluciones
ODL, Ryu
10:30-10:50am BREAK
evolución
Open vSwitch
Orquestadores SDN
y Postman
4:00-4:20pm BREAK
Learning, Traffic Engineering,
802.1X en SDN
SDN

Proyectos de Investigación en SDN

Proyectos de Investigación en SDN
Entrar aquí y ver la lista de proyectos SDN:
https://docs.google.com/spreadsheets/d/1NHI4MZZWVDpxF_Rs7OOSTUa_aHL2
ACUVA_Ov-YQs1DA/edit?usp=sharing

Machine Learning y SDN: Data
Collection and Traffic Classification
M.L in SDN Data Collection and Traffic
Collection

Machine Learning y SDN:
Predicting Network Attack Pattern in SDN
using Machine Learning Approach
Arquitectura basada en M.L para definir
reglas de seguridad sobre un controlador
SDN
-Uso de algoritmos M.L sobre un
conjunto de datos de ataques
históricos (Longtail Project) para
predecir el host que estaría atacado.
- Bloquear un subconjunto particular
como un conjunto en vez que
bloquear direcciones IPs individuales.

802.1x y SDN
Source: Paper AuthFlow Authentication and Access Control Mechanism for Software Defined Networking

PUCPLight: An SDN/OpenFlow Controller
for an Academic Campus Network
Testing y Validación
1. Validación del PUCPLIght
sobre redes simuladas
2. Prueba de esfuerzo sobre
hardware
Evaluación del Rendimiento
1. Mejor explotación de la
capacida sobrante
2. Mejor escalabilidad

Mininet-Wifi
Mininet-WiFi es un Fork de Mininet (http://mininet.org/) y que permite el uso de
Access Points y estaciones WiFi al mismo tiempo. Mininet-WiFi solamente
adiciona características WiFi para que puedas trabajar con Mininet y estaciones
base

Primera capacitación en sdn para el proyecto Bella-T

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Primera capacitación en sdn para el proyecto Bella-T

Similar a Primera capacitación en sdn para el proyecto Bella-T (20)

Más de Open Networking Perú (Opennetsoft)

Más de Open Networking Perú (Opennetsoft) (9)

Último

Último (20)

Primera capacitación en sdn para el proyecto Bella-T