primera capacitación en sdn para el proyecto bella-t

Redes Definidas por Software (SDN)

Javier Richard Quinto [email protected]

[email protected]

mailto:[email protected]

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 enlacedistribuido

Estado de configuración estática

Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN

Redes en la PrácticaTeorí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

Camino a la EvoluciónCumulus 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 packetsSource: 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 reglasSource: Adapted from J. Rexford

Rediseñar la Red!

Recoger mediciones y configurar equipamientos

Plano de Gestión: Escala de tiempo

Source: Adapted from J. Rexford

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

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



Arquitectura SDN y NFV

Origen del Termino SDN

Source: http://www2.technologyreview.com/news/412194/tr10-software-defined-networking/


Plano logicamente centralizado

API al Plano de Datos (e.g., OpenFlow)

Inteligente & Lento

Tonto & Rápido

Source: Adapted from J. Rexford


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

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



Modelos SDN

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

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



Controladores SDN

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-comprehensive-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-controllers/

https://www.sdxcentral.com/brocade/

https://www.sdxcentral.com/cisco/datacenter/

https://www.sdxcentral.com/hpe/networking/

https://www.sdxcentral.com/juniper/

https://www.sdxcentral.com/nec/netcracker/

https://www.sdxcentral.com/nokia/nuage/

https://www.sdxcentral.com/brocade/







Open DayLight (Lithium)

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.

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



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-SR4sudo ./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-allopendaylight-user@root> feature:install odl-l2switch-switchopendaylight-user@root> feature:install odl-restconfopendaylight-user@root> feature:install odl-mdsal-apidocsopendaylight-user@root> bundle:list |grep ActiveCrearemos un escenario mininet indicando como controlador al ODL $ sudo mn --mac --switch ovsk --controller remote

Conectando al cotrolador remoto en: 127.0.0.1:6653is_connected: true

Controlador Open DayLightUna 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?

http://localhost:8181/index.html

Controlador Open DayLight

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:nodes/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

https://github.com/richardqa/SDNLab/blob/master/XML/sample.xml

https://github.com/richardqa/SDNLab/blob/master/XML/sample.xml

http://192.168.56.103:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/



Controlador Ryu

Components:Provides interface for control and state and generates eventsCommunicates using message passing

Libraries:Functions called by componentsEx: 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

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



Interfaces SDN

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.

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



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

OpenFlow y SDN

Entradas de tabla de flujos

Source: https://www.sdxcentral.com/sdn/definitions/what-is-openflow/

A Quick Jump Into SDN

SDN no es OpenFlowpero ...

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.3Los mismos conceptos

Forwarding basados en flujo.Información acerca del control de eventos en la red y

modifcación del estado del equipamiento

Diferentes CapacidadesOpenFlow 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 TableLookup and forwarding

OpenFlow Channel Comunicación entre el SW y el controlador

Meter Table Mecanismo simple QoS.Disponible desde OpenFlow 1.3

Tabla de FlujosContiene 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

OpenFlow 1.3 Pipeline

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 forwardingType FunctionAll Broadcast, Multicast

Select Algorithm chooses the bucket

Indirect Only one bucket

Fast Failover Executes first live bucket

Meter Table

Band Type FunctionDrop 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 MensajesController-to-Switch

AsynchronousEnviado por el switch sin requerimiento del controlador

SymmetricEnviado 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

ReactiveLos 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

ProactiveEl 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

Open SDN Migration Use Cases

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)

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



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.

Ofsoftswitch13CPqD y Ericsson OpenFlow 1.3 software switch, basado sobre el switch de

referencia de Stanford

Ryu controllerRyu 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 OpenFlowmininet> sh ovs-ofctl show s1 -O OpenFlow13

Descripción del Switch OpenFlowmininet> 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 OpenFlowmininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13

Estadísticas de puertos de los switches OpenFlowmininet> sh ovs-ofctl dump-ports s1 -O OpenFlow13

Mininet con switch “user”Primero, cerremos nuestra topología mininet actual: $ mn -cEl 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

Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



Interfaces RESTFul y CURL

RESTFul y CURL

RESTFul y CURL

Creando una entrada OpenFlow del tipo Dropcurl -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/sampleflow

Consultando un flujo determindocurl -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 determinadocurl -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 Bridgecurl -u admin:admin -H 'Content-Type: application/json' -X POST http://IP:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/HOST1/br1

http://11.1.1.5:8080/controller/nb/v2/flowprogrammer/default/node/OF/00:00:fa:0c:cf:b3:56:42/staticFlow/flow4



Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK



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

https://github.com/richardqa/SDNLab.git

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/learningswitch/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/deployd) Ir al directorio “Target” del programa:export target1=~/SDNLab/learning-switch/implementation/targetexport target2=~/SDNLab/tapapp/implementation/target (corregir en la VM)e) Ir al directorio de trabajo “Learning Switch”: export program1=~/SDNLab/learning-switchf) 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 ODLfeature:list # Listar todos los features disponible en ODLfeature: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!)

Topologia basada en Mininet

Learning-Switch

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 1cd $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-switch189 | 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 showis_connected: true

4. Intentemos hacer Ping entre “host1” y “host2”mininet> h1 ping h2From 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 79toprivate 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 -nsucp $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

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

Flow Programming Through REST

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

mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13OFPST_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 h2PING 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 ms64 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)

TAP Application

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.javaLa solución se encuentra en: $tapapp/TutorialTapProvider.unidirectional.solution (ojo: Reiniciar mvn)


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


Par verificar, podrías abrir el browser e inspeccionar la data en http://localhost:8181/restconf/config/tap:tap-spec

http://localhost:8181/restconf/config/tap:tap-spec




4. Abrimos Postman e importamos el archivo XML almacenado en la ruta: ~/XML/tap.xml


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-spec7. 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> sh ovs-ofctl dump-flows s1 -O OpenFlow13mininet> h1 ping h2

9. Finalmente, borramos estos flujos usando reglas Delete dummy


Agenda






10:30-10:50am BREAK







4:00-4:20pm BREAK

4:20-4:50pm Desafios Actuales: Machine Learning, Traffic Engineering, Seguridad


Desafios Actuales

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






10:30-10:50am BREAK







4:00-4:20pm BREAK

4:20-4:50pm Desafios Actuales: Machine Learning, Traffic Engineering, 802.1X en 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_aHL2ACUVA_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-WifiMininet-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

http://mininet.org/

Preguntas?

primera capacitación en sdn para el proyecto bella-t

Technology