Redes Definidas por Software:

Un nuevo enfoque en la Red

Javier Richard Quinto A.

javierquinto@opennetsoft.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
Sigueme a: INICTEL-UNI
fb.com/
@opennetsoft -Mis fortalezas: SDN, P4, NFV, Cloud,
opennetsoft

Seguridad IPv4/IPv6, AAA/802.1x

Problematica y Estrategias de
Solución en las Redes
Convencionales
 Equipamiento de Redes Propietarias

Componentes

Switches de
redes
Custom
Silicon

Verticalmente integrado, complejo, cerrado y propietario!

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 de
Estado enlace configuración estática
distribuido

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

 Redes en la Práctica
Teoria 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 Merchant Facebook

Silicon Silicon
 Camino a la Evolución

Existentes Nuevas

- CLIs - APIs
- Código cerrado - Código abierto
- Proporcionado por el - Proporcionado por el
proveedor cliente
- Aplicaciones conocidas - 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 integrado Horizontal

Cerrado, propietario Interfaces abiertas
Innovación lenta Rápida inovación
Rediseñar la Red!

Plano de Datos:
Streaming de paquetes

Forward, Filter, Buffer, Mark, rate-limit, and

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
Source: Adapted from J. Rexford
Rediseñar la Red!

Plano de Gestión:
Escala de tiempo

Recoger mediciones y configurar equipamientos

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

Inteligente API al Plano de Datos

& Lento (e.g., OpenFlow)

Tonto &
Rápido

Source: Adapted from J. Rexford

 Redes Definidas por Software (SDN)

Agilidad y Flexibilidad

Centralmente gestionado

Estándares abiertos y
neutral al vendor

Directamente Programable

Source: https://www.opennetworking.com
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

- Ahorro en espacio y
energía

- Innovación más rápida

- Asignación flexible de
recursos

- Multiplicidad de usuarios

- Mayor rentabilidad
Source: https://www.opennetworking.com , Network Function Virtualization: Perspectivas, Realidades e Desafios
 Open Networking

Source: Porqué los Tier-1 están adoptando las SDN y nFV?, whitestack
Certificaciones ONF: SDN/Openflow
SDN vs NFV
Flexibilidad y Programabilidad en la Red
(SDN & NFV)

Sources: Ahmad Rostami, Ericsson Research (Kista):

http://www.itc26.org/fileadmin/ITC26_files/ITC26-Tutorial-Rostami.pdf and Uwe Michel, T-Systems
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
Definición según la ONF:

The physical separation of the network control

plane from the forwarding plane, and where a
control plane controls several devices.

SDN no es OpenFlow
pero ...
OpenFlow si es SDN
 Openflow y SDN

Beneficios de
Openflow

- Programabilidad

- Inteligencia
centralizada

- Abstracción

Aquí es en donde Openflow

si encajaría sobre SDN
 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
Version Release

0.8.0 May, 5, 2008

La más reciente versión de 0.8.1 May, 20, 2008
OpenFlow es la 1.5.1 0.8.2 Oct, 17, 2008

0.8.9 Dec, 2, 2008

Cada nueva versión mejora el 0.9.0 Jul, 20, 2009

protocolo y adiciona nuevas 1.0 Dec, 31, 2009

1.1 Feb, 28, 2011

características 1.2 Dec 2011

1.3 Jun, 25, 2012

Desafortunadamente los 1.3.1 Sep, 6. 2012

dispositivos hardware con soporte 1.3.2 Apr, 25, 2013

1.4.0 Oct, 14, 2013

Openflow usan, en su mayoria, la 1.5.0 Dec, 19, 2014
versión 1.0 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
Flow Table
Lookup y forwarding

OpenFlow Channel
Comunicación entre el SW y el
controlador
Group Table
Opciones adicionales para reenviar
paquetes Disponible desde OpenFlow 1.1
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

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
OpenFlow 1.0 OpenFlow 1.3
Output Output

Drop Set-Queue

Set VLAN ID Drop

Set VLAN priority Group

Strip VLAN header Push-Tag/Pop-Tag

Modify Ethernet, IPv4. Set-Field
transport src/dst address

Enqueue Change-TTL
 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
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
Después de establecer la conexión del TCP/TLS, ambos lados envian
mensajes “Hello Message”

Switch Controller

Hello Message
Solves the Hello. If
Solves the OpenFlow
the version is not
version
supported sends an
Error message

Features Request

Features Reply

OpenFlow Connection
Established
Controlador OpenFlow

I want to talk with

the Desktop!

OpenFlow
Controlador OpenFlow

Oh God! What
I’m gonna do?

OpenFlow
Controlador OpenFlow

I’m here for you! Take

the power of the
Learning Switch!

OpenFlow

OpenFlow Channel

THE almighty
OpenFlow Controller
Network OS
El 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
Proactive
El 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

Reactive
Los 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
Arquitectura de Controladores

Centralized Distributed
Popular Open Source controllers

Phyton
Java Java

Phyton 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.

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’ .

Eth0 Switch S1 Eth1

Eth0 Eth1

Host H1 Host H2
 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 h2
Notas algún cambio cuando tipeas “h1 ping h2” en el prompt del
mininet?
 OVS-OFCTL

Comandos para enviar mensajes directamente al Open vSwitch

Switch Capabilities
mininet> sh ovs-ofctl show s1 -O OpenFlow 13

Switch Description
mininet> 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 state

mininet> sh ovs-ofctl dump-flows s1 -O OpenFlow13

Port statistics
mininet> 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-SR4
sudo ./bin/karaf

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

Acceso al directorio Ryu y ejecución del controlador

cd ~/ryu
sudo ./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-SR4
sudo ./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

 Wireshark
Mediante 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 Configuration
Para 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 1

cd $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-switch
189 | Active | 80 | 1.0.0.SNAPSHOT org.sdnhub.odl.tutorial.learning-switch.impl
 Setup Configuration
3. 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 h2
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

Porqué el Ping falla?

5. Add the next rule and verify the ping

mininet> s1 ovs-ofctl add-flow tcp:127.0.0.1:6654 -OOpenFlow13
priority=1,action=output:controller
mininet> h1 ping -c 10 h2
 Setup Configuration
6. 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 79
to
private String function = "switch";
 Setup Configuration
8. 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 program
mvn install -nsu
cp $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 remote
mininet > h1 ping -c 10 h2
Notas cambios en el RTT obtenido en el paso 5 y 9? Que sucedió?
Preguntas?