capacitación de sdn para comsoc uni

Redes Definidas por Software: Un nuevo enfoque en la Red

Javier Richard Quinto [email protected]

[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 a:

Problematica y Estrategias de Solución en las Redes

Convencionales

Equipamiento de Redes Propietarias

Verticalmente integrado, complejo, cerrado y propietario!

Custom Silicon

Switches de redes

Componentes

No recomendable para propietarios de redes ni para usuarios

Problematicas 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ácticaTeoria y práctica son lo mismos, 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


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

La Tendencia en Computación

Verticalmente integradoCerrado, propietarioInnovación lenta

HorizontalInterfaces abiertasRápida inovación

Rediseñar la Red!

Plano de Datos: Streaming de paquetes

Forward, Filter, Buffer, Mark, rate-limit, and 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 wired

● Equipamientos más simple y más fácil

Más uso de software

Arquitectura SDN y NFV

Origen del Termino SDN

Redes Definidas por Software (SDN)

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

Open Networking

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

Certificaciones ONF: SDN/Openflow

SDN vs NFV

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)

Diferentes Modelos de SDN

Modelo: Open SDN

- Estándard abiertos- Software de código

abierto- APIs and SDKs- Hardware abierto

Modelo: Hybrid SDN

- 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

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

OpenFlow y SDN

Interface Programable

Permite el acceso directo y manipulación del plano de forwarding de los dispositivos de redes tales como switches y routers, ambos físicos o virtuales (basado en hypervisor).

Las primitivas básicas que pueden ser usadas por una app. de software externa para programar el plano de forwarding puede ser comparada al conjunto de intrucción de un CPU.

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 OpenFlowComponentes principales

Group Table Opciones adicionales para reenviar paquetes Disponible desde OpenFlow 1.1

Flow TableLookup y 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.0 Pipeline

OpenFlow 1.0 does not have multiple tables!

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 Actions

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

Controlador OpenFlow

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!

Network OSEl controlador puede ser visto como un sistema operativo de red en donde las aplicaciones pueden ser construidas sobre el TOP de éste sistema operativo.

Proactive vs Reactive Flows

ReactiveLos flujos que no se encuentran en la tabla de entrada de flujos del switch son enviados al controlador, que instala estos flujos basados sobre los campos del paquete. El paquete es luego enviado nuevamente al switch para su debido procesamiento.Ejemplo de aplicación: Learning Switch

ProactiveEl controlador instala los flujos antes que el tráfico de paquetes llegue al switch. Éste modelo es usado cuando nosotros ya sabemos el tráfico que queremos manejar.Ejemplo de aplicación: Packet Monitor

Arquitectura de Controladores

Centralized Distributed

Popular Open Source controllers

Phyton

Phyton

Java Java

C/Ruby

Problematica de OpenFlow

Configuración Run-Time

Capa Independiente del Protocolo

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

Open SDN Migration Use Cases

Casos de Uso (Open Source)

1. 6.4% of all Internet Traffic (ATLAS, 2010)

2. Google has two large Backbones networks:Internet facing (user traffic)Datacenter Traffic (Internal)

3. Google WAN intensive applications:Youtube, Websearch, Google+, Hangouts, Maps, AppEngine, Android and Chrome updates.

Casos de Uso (Ciberseguridad)

Hands On:Mininet con

Openflow1.0 y 1.3

Herramientas instaladas en Ubuntu 16.04

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

El controlador de referencia local (ref) usa OpenFlow 1.0 por defecto. Para usar OpenFlow 1.3, indicar el parametro “protocols=OpenFlow13”. Por ejemplo:$ 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

Adicionando reglas estáticas usando 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 h2Notas algún cambio cuando tipeas “h1 ping h2” en el prompt del mininet?

OVS-OFCTL

Comandos para enviar mensajes directamente al Open vSwitch

Switch Capabilitiesmininet> sh ovs-ofctl show s1 -O OpenFlow 13

Switch Descriptionmininet> sh ovs-ofctl dump-desc s1 -O OpenFlow13

Add Flow mininet> sh ovs-ofctl -O OpenFlow13 add-flow s1 priority=100,in_port=1,actions=output:2

Flow Table statemininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13

Port statisticsmininet> sh ovs-ofctl dump-ports s1 -O OpenFlow13

Dpctl con switch “user”El switch software OpenFlow 1.3 tiene una similar herramienta al ovs-ofctl: “sudo mn --switch user --controller ref”

Capacidades del switch$ sudo dpctl unix:/tmp/s1 features

Descripción del switch$ sudo dpctl unix:/tmp/s1 stats-desc

Adicionar flujos$ sh dpctl unix:/tmp/s1 flow-mod cmd=add,table=0 in_port=1 apply:output=2$ sh dpctl unix:/tmp/s1 flow-mod cmd=add,table=0 in_port=2 apply:output=1

Estado de la tabla de flujos$ sudo dpctl unix:/tmp/s1 stats-flow

TCP bandwith

Testing TCP bandwidth entre hosts con Iperf

$ sudo mn --switch user --test iperf Results: [‘54.9 Mbits/sec', '60.6 Mbits/sec']

$ sudo mn --switch ovsk --test iperf Results: ['7.06 Gbits/sec', '7.06 Gbits/sec']

Note que en el primer caso se consigue un BW en Iperf TCP mucho menor que comparado a la vista en el segundo caso usando el switch kernel

Ejecución de controladores Ryu y ODL

# Open DayLigth (https://www.opendaylight.org/downloads)

Acceso al directorio ODL y ejecución de Karaf

cd ~/distribution-karaf-0.4.4-Beryllium-SR4sudo ./bin/karaf

# Ryu Controller (https://github.com/osrg/ryu)

Acceso al directorio Ryu y ejecución del controlador

cd ~/ryusudo ./bin/ryu-manager --verbose ryu/app/simple_switch_13.py

https://github.com/osrg/ryu

Controlador Ryu

Components:Proporciona interface para control y estado y genera eventos.

Libraries:Funciones llamadas por los componentes:Ex: OF-Config, Netflow, sFlow, Netconf, OVSDB

Controlador Open DayLight

Ryu Controller con OpenFlow 1.3

El comando debajo inicia el controlador mediante la llamada al Handler del protocolo Openflow y la aplicación Simple Switch 1.3

cd /home/ubuntu/ryu./bin/ryu-manager --verbose ryu/app/simple_switch_13.py

Creamos la topología del mininet. Para controladores remotos, por defecto OpenFlow 1.3 esta configurado

sudo mn --topo single,3 --mac --controller remote --switch ovsk

Comando para listar los flujos en memoria del Open vSwitch

sudo ovs-ofctl dump-flows s1

OpenDayLight con OpenFlow 1.3

Hacemos lo mismo, pero usando el controlador Open DayLight

cd ~/distribution-karaf-0.4.4-Beryllium-SR4sudo ./bin/karaf

Creamos la topología del mininet. Para controladores remotos, por defecto OpenFlow 1.3 esta configurado

sudo mn --topo single,3 --mac --controller remote --switch ovsk

Comando para listar los flujos en memoria del Open vSwitch

sudo ovs-ofctl dump-flows s1

WiresharkMediante el uso de otro terminal, iniciar Wireshark y escoger la interface Loopback. Escoger tipo de filtro: “openflow_v4”

Simple Learning Switch

● Un “Learning switch” es un equipo un poco más inteligente en capa 2.

● El switch aprende la MAC y el puerto desde los paquetes que llegan a sus interfaces.

● Si el switch no sabe el destino MAC, éste inunda el paquete a todas las interfaces y luego aprende la MAC y el puerto. De otra manera, éste reenvia al puerto asociado con la MAC destino.

OpenFlow Learning Switch

● La aplicación “learning-switch” en OpenFlow hace lo siguiente:

○ Cuando el switch no tiene un flujo que mapee una MAC a un puerto, éste enviaría el paquete (packet_in) al controlador. Por defecto, OpenFlow 1.0 envia el packet-in al controlador, el OpenFlow 1.3 pierde dicho flujo si una entrada de flujo explicitamente no indica esto.

○ El controlador aprenderá la MAC source y el puerto en donde el paquete llegó, instala flujo con éstos campos y envia el paquete de retorno (Packet Out) con una acción de salida del tipo Flood.

○ Paquetes subsecuentes con destino igual a la MAC aprendida son reenviadas directamente al destino.

Hands On:Mininet con Openflow 1.3 y Open DayLight

Setup ConfigurationPara el presente tuorial, nosotros vamos a convertir un HUB a un switch de aprendizaje MAC que programa flujos.

1. Start the ODL controller in debug mode # Terminal 1cd $control./karaf debug

2. Verify if the feature “sdnhub-tutorial-learning-switch” is installed> feature:list -i |grep sdnhub-tutorial-learning-switch

If it is not installed, install it

> feature:install sdnhub-tutorial-learning-switch

Wait 30 seconds until the Learning-Switch program is installed and active

> bundle:list -s |grep learning-switch189 | Active | 80 | 1.0.0.SNAPSHOT org.sdnhub.odl.tutorial.learning-switch.impl

Setup Configuration3. Start mininet topology # Change to a second terminal (Terminal 2)

sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13 --controller remote

* We wait until the controller is connected to the mininet topology: is_connected: true

4. Try to do ping between “host1” and “host2”mininet> h1 ping h2From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

Porqué el Ping falla?

5. Add the next rule and verify the pingmininet> s1 ovs-ofctl add-flow tcp:127.0.0.1:6654 -OOpenFlow13 priority=1,action=output:controller

mininet> h1 ping -c 10 h2

Setup Configuration6. Open the learning-switch program ($learn/TutorialL2Forwarding.java) and pay attention in the lines #79 and #143

In the line #79 you may note that the default function of the code is in “hub mode”. This means that our program (learning-switch) will act as hub, thus ping between hosts would have a high RTT value, as you can see above. In the line #143 you may note the code block related to the behavior of the program.

7. In the same file TutorialL2Forwarding.java, change the default function of the program from “hub” to “switch”.

private String function = "hub"; # Line 79toprivate String function = "switch";

Setup Configuration8. Update maven from the path of the program and copy the “JAR” generated by maven to the folder “deploy” of our controller

cd $program1 # Path of the learning-switch programmvn install -nsucp $target/learning-switch-impl-1.0.0-SNAPSHOT.jar $deploy/

9. Restart “mininet” and the “controller” and do ping between h1 and h2 again:> logout # Logout to the controller./karaf debug # Start the controller again

mininet > exit # Exit to the mininet$ mn -c # Clean mininet$ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13 --controller remotemininet > h1 ping -c 10 h2

Notas cambios en el RTT obtenido en el paso 5 y 9? Que sucedió?

Preguntas?

capacitación de sdn para comsoc uni

Technology