Capacitación de SDN para COMSOC UNI
-
Upload
open-networking-peru-opennetsoft -
Category
Technology
-
view
170 -
download
5
Transcript of Capacitación de SDN para COMSOC UNI
Redes Definidas por Software: Un nuevo enfoque en la Red
Javier Richard Quinto [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
Camino a la Evolución
Source: Introduction to OpenFlow, SDN and NFV, Kingston Smiler
Camino a la Evolución
Custom Silicon
Merchant Silicon
Camino a la Evolución
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
Redes Definidas por Software (SDN)
Source: https://www.opennetworking.com
Directamente Programable
Agilidad y Flexibilidad
Centralmente gestionado
Estándares abiertos y neutral al vendor
Redes Definidas por Software (SDN)
Nuevas habilidades y oportunidades
Herramientas sofisticadas
Reduce CapEx/OpEx
Redes Definidas por Software (SDN)
Redes Definidas por Software (SDN)
Source: N. Mckeown et al.
Redes Definidas por Software (SDN)
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
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
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!
Controlador OpenFlow
OpenFlow
Oh God! What I’m gonna do?
Controlador OpenFlow
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)
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
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?