Instalacion OpenWRT TP-Link TL-WR1043ND en Windows

 

Configuracion OpenWRT en TPLink TL-WR1043ND

1)Descarga de OpenWRT para TP-Link TL-WR1043ND V3.

OpenWRT wiki del router:

https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd

Link de descarga:

https://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/openwrt-ar71xx-generic-tl-wr1043nd-v3-squashfs-factory.bin

 

2) Debido a que el TP-Link viene con una versión que no permite instalar software de terceros no se puede instalar desde la interfaz web del router.

Por lo tanto, para la instalación se utiliza el software llamado TFTPD que permite el intercambio mediante TFTP que es un protocolo de transferencia de archivos similares a FTP. (http://tftpd32.jounin.net/)

3) Luego de instalarlo en una carpeta ubican el archivo descargado del firmware del OpenWRT y lo renombran a “wr1043v3_tp_recovery.bin”.

4) Con el router conectado y encendido se le asigna una dirección IPv4 desde el panel de control, como por ejemplo la siguiente:

5) Se abre TFTPD y se busca la carpeta en donde se ubica el firmware del OpenWRT y en “Server Interfaces” se escoge la dirección previamente escogida para el router.

6) Apagar el router. Manteniendo presionado el botón de reset se presiona una vez el botón de encendido, manteniendo el reset hasta que en TFTPD se termine de instalar OpenWRT.

Al finalizar esto, ya se tiene OpenWRT instalado en el router pero queda por instalar la interfaz web. Previamente a este último paso eliminamos la dirección IP asignada y seleccionamos que la obtenga automáticamente.

7) Descargar y abrir Putty (https://www.putty.org/) y entrar a “192.168.1.1” con el usuario root:

Por último, se escribe opkg update && opkg install luci.

Ya se puede acceder desde el navegador con “192.168.1.1”:

Instalacion OpenWRT en Tp-Link TL-WR1043ND Ver:3.0

Flasheo de OpenWRT Chaos Claimer (15.05) en TL-WR1043ND revision v3 via tftp.

1- Descargar v2 15.05 factory image v2 15.05

2- Cambiar el numero de versión en el header del archivo de 02 a 03:
echo -e "\003" | dd seek=67 bs=1 count=1 conv=notrunc of=firmware_file.bin
Reemplazar firmware_file.bin por el nombre del archivo descargado.

3- Cambiar el nombre del archivo a wr1043v3_tp_recovery.bin

4- Instalar servidor tftp, en ubuntu 16.04:
sudo apt-get install tftpd-hpa

5- Confirmar el funcionamiento del servidor
sudo service tftpd-hpa status

6- Mover el archivo de firmware al directorio tftpboot:
mv wr1043v3_tp_recovery.bin /var/lib/tftpboot/

7- Cambiar la ip del host a 192.168.0.66

8- Enchufar el router mientras presionamos el botón de reinicio por unos segundos. Todos LEDs del router se encienden indicando que el se esta subiendo el archivo.

9- Cambiamos las ip del host a 192.168.1.10. Abrimos sesión telnet a 192.168.1.1

Instalacion de Chaos Clamer 15.05.1

1- En OpenWRT asignar un password con el comando passwd para habilitar ssh

root@OpenWrt:/# passwd
Changing password for root
New password:
Retype password:
Password for root changed by root
root@OpenWrt:/#

2- Descargar Chaos Calmer 15.05.1 stable for v2

3- Copiar el firmware descargado a /tmp/ del router mediante scp.
scp openwrt-15.05.1-ar71xx-generic-tl-wr1043nd-v2-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/

5- En el router ejecutamos sysupgrade para el flasheo de la nueva imagen:
sysupgrade -n -F /tmp/openwrt-15.05.1-ar71xx-generic-tl-wr1043nd-v2-squashfs-sysupgrade.bin

6- Esperamos unos segundos. Luego del reinicio abrimos sesion telnet y observamos el cambio a 15.05.1.

Actividad 01: flujos en Open vSwitch

Topologia:

Iniciamos mininet
mn --topo=single,4 --controller=none --mac
Comprobamos que no haya conectividad y el switch no contiene flujos

Agregamos entradas arp en los host para evitar el arp broadcast

Agregamos flujos para conectar h1 con h2

Solo hay conexión entre h1 y h2

Flujos insertados:

priority, indica la prioridad del flujo.
ip, indica que protocolo de red usamos.
nw_dst, dirección de red destino.
actions=1, la acción que se toma cuando hay un match, enviarlo a través del puerto 1.

Agregamos un flujo de menor prioridad para descartar todos los paquetes:

Al ser de menor prioridad no hay match y los paquetes no son descartados.

Un flujo igual de mayor prioridad descarta los paquetes

Matching en capa 2

Sin manejo de arp

Agregamos entradas arp a los host h3 y h4

Agregamos un flujo para conectar h3 con h4 usando flujos de capa 2

Con manejo de arp

Eliminamos las entradas arp de los host y agregamos el flujo para manejar el trafico arp

El flujo consiste de:
dl_type=0x806, es el EtherType ARP. El protocolo encapsulado en la trama Ethernet es ARP. Equivalente al keyword arp en el flujo
nw_proto=1,  indica que se trata de una solicitud ARP.
actions=flood, envía el paquete a todos los puertos excepto al puerto que recibió el paquete.

Es posible manipular el tráfico arp para evitar el broadcast

Con los cuatro primeros flujos evitamos el broadcast del tráfico arp.

Pruebas con Open vSwitch y Facuet

Instalación Faucet

apt-get install python-dev
apt-get install python3-pip
pip3 install faucet

mkdir -p /etc/ryu/faucet
mkdir -p /var/log/ryu/faucet
mkdir -p /var/log/ryu/gauge
touch /etc/ryu/faucet/gauge.yaml

Archivo de configuración Faucet

cat << 'EOF' > /etc/ryu/faucet/faucet.yaml
dps:
switch-1:
dp_id: 0x1
timeout: 3600
arp_neighbor_timeout: 3600
interfaces:
1:
native_vlan: 10
2:
native_vlan: 10
3:
native_vlan: 20
4:
native_vlan: 20
vlans:
10:
20:
EOF

Iniciar Open vSwitch

ovs-vsctl add-br br0 \
-- set bridge br0 other-config:datapath-id=0000000000000001 \
-- add-port br0 p1 -- set interface p1 ofport_request=1 \
-- add-port br0 p2 -- set interface p2 ofport_request=2 \
-- add-port br0 p3 -- set interface p3 ofport_request=3 \
-- add-port br0 p4 -- set interface p4 ofport_request=4 \
-- set-controller br0 tcp:127.0.0.1:6653 \
-- set controller br0 connection-mode=out-of-band

Iniciamos Faucet y observamos el log

ryu-manager faucet.faucet –verbose

root@vm:~# cat /var/log/ryu/faucet/faucet.log
Dec 20 16:05:57 faucet INFO Add new datapath DPID 1 (0x1)
Dec 20 16:06:05 faucet INFO DPID 1 (0x1) connected
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Cold start configuring DP
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Configuring VLAN 10 vid:10 ports:Port 1,Port 2
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Configuring VLAN 20 vid:20 ports:Port 3,Port 4
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Port 1 up, configuring
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Port 2 up, configuring
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Port 3 up, configuring
Dec 20 16:06:05 faucet.valve INFO DPID 1 (0x1) Port 4 up, configuring

Tablas

Tabla 0 para ACL basado en puertos. Redirige el tráfico hacia la tabla 1

ubuntu@vm:~/openvswitch-2.8.1/tutorial$ dump-flows br0 | head -n5
priority=9099,in_port=p1 actions=goto_table:1
priority=9099,in_port=p2 actions=goto_table:1
priority=9099,in_port=p3 actions=goto_table:1
priority=9099,in_port=p4 actions=goto_table:1
priority=0 actions=drop

Tabla 1

Esta tabla se encarga del manejo de etiquetas VLAN.

ubuntu@vm:~/openvswitch-2.8.1/tutorial$ dump-flows br0 | grep table=1
table=1, priority=9099,dl_dst=01:80:c2:00:00:00 actions=drop
table=1, priority=9099,dl_dst=01:00:0c:cc:cc:cd actions=drop
table=1, priority=9099,dl_type=0x88cc actions=drop
table=1, priority=9000,in_port=p1,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4106->vlan_vid,goto_table:3
table=1, priority=9000,in_port=p2,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4106->vlan_vid,goto_table:3
table=1, priority=9000,in_port=p3,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4116->vlan_vid,goto_table:3
table=1, priority=9000,in_port=p4,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4116->vlan_vid,goto_table:3
table=1, priority=0 actions=drop

Tabla 2

Esta tabla se encarga de el ACL a nivel de VLAN. La tabla esta vacia ya que no especificamos ningún parámetro.

Tabla 3

Se encarga del procesamiento en capa 2 y aprender direcciones MAC.

ubuntu@vm:~/openvswitch-2.8.1/tutorial$ dump-flows br0 | grep table=3
table=3, priority=9099,dl_src=ff:ff:ff:ff:ff:ff actions=drop
table=3, priority=9001,dl_src=0e:00:00:00:00:01 actions=drop
table=3, priority=0 actions=drop
table=3, priority=9000 actions=CONTROLLER:96,goto_table:7

Tablas 4,5,6

Se usan para ruteo. Están vacías ya que no configuramos ruteo.

Tablas 7 y 8

La tabla 7 se usa para redirigir paquetes a direcciones MAC aprendidas. La tabla 8 implementa flooding, broadcast y multicast.

Generar trafico

Con la herramienta ofproto/trace podemos observar el camino que toma un paquete

ubuntu@vm:~$ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02 -generate
Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,dl_type=0x0000

bridge(“br0”)
————-
0. in_port=1, priority 9099, cookie 0x5adc15c0
goto_table:1
1. in_port=1,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0
push_vlan:0x8100
set_field:4106->vlan_vid
goto_table:3
3. priority 9000, cookie 0x5adc15c0
CONTROLLER:96
goto_table:7
7. priority 9000, cookie 0x5adc15c0
goto_table:8
8. in_port=1,dl_vlan=10, priority 9000, cookie 0x5adc15c0
pop_vlan
output:2

Final flow: unchanged
Megaflow: recirc_id=0,eth,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,dl_type=0x0000
Datapath actions: push_vlan(vid=10,pcp=0),pop_vlan,2
This flow is handled by the userspace slow path because it:
– Sends “packet-in” messages to the OpenFlow controller.

Observamos en el log de faucet una nueva entrada perteneciente a la mac aprendida

Dec 20 21:14:48 faucet.valve INFO DPID 1 (0x1) L2 learned 00:00:00:00:00:01 (L2 type 0x0000, L3 src None) on Port 1 on VLAN 10 (2 hosts total)

También verificamos un nuevo flujo en la tabla 3 del switch

ubuntu@vm:~$ dump-flows br0 | grep table=3
table=3, priority=9099,dl_src=ff:ff:ff:ff:ff:ff actions=drop
table=3, priority=9001,dl_src=0e:00:00:00:00:01 actions=drop
table=3, hard_timeout=3599, priority=9098,in_port=p1,dl_vlan=10,dl_src=00:00:00:00:00:01 actions=goto_table:7 # Nueva Entrada
table=3, priority=0 actions=drop
table=3, priority=9000 actions=CONTROLLER:96,goto_table:7

Repetimos el comando pero en dirección contraria. El paquete es enviado al controlador

ubuntu@vm:~$ ovs-appctl ofproto/trace br0 in_port=p2,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01 -generate
Flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,dl_type=0x0000

bridge(“br0”)
————-
0. in_port=2, priority 9099, cookie 0x5adc15c0
goto_table:1
1. in_port=2,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0
push_vlan:0x8100
set_field:4106->vlan_vid
goto_table:3
3. priority 9000, cookie 0x5adc15c0
CONTROLLER:96
goto_table:7
7. dl_vlan=10,dl_dst=00:00:00:00:00:01, priority 9099, cookie 0x5adc15c0
pop_vlan
output:1

Final flow: unchanged
Megaflow: recirc_id=0,eth,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,dl_type=0x0000
Datapath actions: push_vlan(vid=10,pcp=0),pop_vlan,1
This flow is handled by the userspace slow path because it:
– Sends “packet-in” messages to the OpenFlow controller.

Repetimos el comando. El paquete es enviado al puerto 1, sin necesidad de enviarlo al controlador

Ruteo

dps:
switch-1:
dp_id: 0x1
timeout: 3600
arp_neighbor_timeout: 3600
interfaces:
1:
native_vlan: 10
2:
native_vlan: 10
3:
native_vlan: 20
4:
native_vlan: 20
vlans:
10:
faucet_vips: ["10.0.1.254/24"]
20:
faucet_vips: ["10.0.2.254/24"]
routers:
router-1:
vlans: [10,20]

Observamos en la tabla 3 la instalación de nuevos flujos para manejar paquetes ARP. Los paquetes son enviados a la
tabla 6 que se encarga de el procesamiento de paquetes IP. También vemos dos flujos que envían paquetes IP destinados
a una dirección MAC usada por el router a la tabla 4, que maneja el redireccionamiento a nivel capa 3.


ubuntu@vm:~$ dump-flows br0 | grep table=3
table=3, priority=9131,arp,dl_vlan=10 actions=goto_table:6 # Manejo de ARP
table=3, priority=9131,arp,dl_vlan=20 actions=goto_table:6 # Manejo de ARP
table=3, priority=9099,dl_src=ff:ff:ff:ff:ff:ff actions=drop
table=3, priority=9001,dl_src=0e:00:00:00:00:01 actions=drop
table=3, priority=9099,ip,dl_vlan=10,dl_dst=0e:00:00:00:00:01 actions=goto_table:4 # Paquete ip que llegan al router
table=3, priority=9099,ip,dl_vlan=20,dl_dst=0e:00:00:00:00:01 actions=goto_table:4 # Paquete ip que llegan al router
table=3, priority=0 actions=drop
table=3, priority=9000 actions=CONTROLLER:96,goto_table:7

En la tabla 4 aparecen los paquetes que Faucet puede rutear

ubuntu@vm:~$ dump-flows br0 | grep table=4
table=4, priority=9131,ip,dl_vlan=10,nw_dst=10.0.1.254 actions=goto_table:6
table=4, priority=9131,ip,dl_vlan=20,nw_dst=10.0.2.254 actions=goto_table:6
table=4, priority=9123,ip,dl_vlan=20,nw_dst=10.0.1.0/24 actions=goto_table:6
table=4, priority=9123,ip,dl_vlan=10,nw_dst=10.0.1.0/24 actions=goto_table:6
table=4, priority=9123,ip,dl_vlan=20,nw_dst=10.0.2.0/24 actions=goto_table:6
table=4, priority=9123,ip,dl_vlan=10,nw_dst=10.0.2.0/24 actions=goto_table:6
table=4, priority=0 actions=drop

Esta tabla envia los paquetes ARP destinados al router hacia el controlador. Ademas envia los paquetes broadcast a la tabla 8

nicolas@nicolas-vm:~$ dump-flows br0 | grep table=6
table=6, priority=9133,arp,arp_tpa=10.0.1.254 actions=CONTROLLER:128
table=6, priority=9133,arp,arp_tpa=10.0.2.254 actions=CONTROLLER:128
table=6, priority=9132,arp,dl_dst=ff:ff:ff:ff:ff:ff actions=goto_table:8
table=6, priority=9131,arp actions=goto_table:7
table=6, priority=9130,ip actions=CONTROLLER:128
table=6, priority=0 actions=drop

Simulamos un paquete broadcast desde un host en el puerto 1 con ip 10.0.0.1. El paquete es enviado al controlador

nicolas@nicolas-vm:~$ ovs-appctl ofproto/trace br0 "in_port=p1 dl_src=00:00:00:00:00:01 dl_dst=ff:ff:ff:ff:ff:ff \
dl_type=0x806 arp_spa=10.0.1.1 arp_tpa=10.0.1.254 arp_sha=00:00:00:00:00:01 \
arp_tha=ff:ff:ff:ff:ff:ff arp_op=1" -generate
Flow: arp,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.0.1.1,arp_tpa=10.0.1.254,arp_op=1,arp_sha=00:00:00:00:00:01,arp_tha=ff:ff:ff:ff:ff:ff

bridge(“br0”)
————-
0. in_port=1, priority 9099, cookie 0x5adc15c0
goto_table:1
1. in_port=1,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0
push_vlan:0x8100
set_field:4106->vlan_vid
goto_table:3
3. arp,dl_vlan=10, priority 9131, cookie 0x5adc15c0
goto_table:6
6. arp,arp_tpa=10.0.1.254, priority 9133, cookie 0x5adc15c0
CONTROLLER:128 #El paquete es reconocido como un paquete ARP y es enviado al controlador

Final flow: arp,in_port=1,dl_vlan=10,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=00:00:00:00:00:01,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.0.1.1,arp_tpa=10.0.1.254,arp_op=1,arp_sha=00:00:00:00:00:01,arp_tha=ff:ff:ff:ff:ff:ff
Megaflow: recirc_id=0,eth,arp,in_port=1,vlan_tci=0x0000/0x1fff,dl_dst=ff:ff:ff:ff:ff:ff,arp_tpa=10.0.1.254
Datapath actions: push_vlan(vid=10,pcp=0)
This flow is handled by the userspace slow path because it:
– Sends “packet-in” messages to the OpenFlow controller.

Algunos campos

arp_tpa, ARP target protocol address

arp_spa, ARP sender protocol address

arp_sha, ARP sender hardware address

arp_tha, ARP target hardware address

En el log de faucet podemos ver las direcciones MAC aprendidas y el mapeo MAC-IP

ubuntu@vm:/var/log/ryu/faucet# cat faucet.log
...
Dec 22 16:07:18 faucet.valve INFO DPID 1 (0x1) Adding new route 10.0.1.1/32 via 10.0.1.1 (00:00:00:00:00:01) on VLAN 10
Dec 22 16:07:18 faucet.valve INFO DPID 1 (0x1) Responded to ARP request for 10.0.1.254 from 10.0.1.1 (00:00:00:00:00:01) on VLAN 10
Dec 22 16:07:18 faucet.valve INFO DPID 1 (0x1) L2 learned 00:00:00:00:00:01 (L2 type 0x0806, L3 src 10.0.1.1) on Port 1 on VLAN 10 (1 hosts total)
...

CACIDI
2018

CONGRESO ARGENTINO DE CIENCIAS DE LA INFORMÁTICA Y DESARROLLOS DE INVESTIGACIÓN 2018

logo ieee letras negras

28, 29 y 30 de Noviembre de 2018

El CACIDI es organizado de manera conjunta por la Escuela de Ciencia y Tecnología de la Universidad Nacional de San Martín y la Universidad CAECE.

El objetivo del CACIDI es la promoción y generación de ideas y modelos tecnológicos de investigaciones en Networking technologies, High Performance Computing, Health-Care Technology, Programming language theory, entre otros, favoreciendo el intercambio entre especialistas, estudiantes y docentes investigadores a nivel local, regional e internacional.

El Congreso tiene sus antecedentes en UNSAM IT DAY (Information Technology Day) y CACIDI 2016. 
UNSAM IT DAY fué un evento interuniversitario organizado en 2014 por el Centro de Investigación y Desarrollo en Informática (CIDI) de la UNSAM, que cumplió con su objetivo de promover y compartir los conocimientos y las aplicaciones más novedosas en Tecnologías de la Información y la Comunicación.
CACIDI 2016 tuvo lugar en el auditorio de la Facultad de Ciencias Económicas de la UBA  -Uriburu 781, C.A.B.A., Argentina- el 30 de noviembre al 2 de diciembre de 2016. Los trabajos seleccionados durante el Congreso, fueron publicados por Institute of Electrical and Electronics Engineers (IEEE).

IEEE es la mayor organización profesional técnica del mundo dedicada al avance de la tecnología en beneficio de la humanidad y sus miembros inspiran a una comunidad global de innovación para un futuro mejor a través de sus publicaciones altamente citadas en conferencias, estándares de tecnología y las actividades profesionales y educativas.

Hay más de 420.000 miembros del IEEE en más de 160 países. IEEE publica una tercera parte de la literatura técnica del mundo en ingeniería eléctrica, informática y electrónica, y es líder en el desarrollo de normas internacionales que sustentan muchas de las telecomunicaciones de hoy en día, la tecnología de la información y los productos y servicios de generación de energía.

CACIDI 2018
Ciudades Inteligentes
Ingeniero Luis Marrone
CACIDI 2018
Reconocimiento
Ingeniero Luis Marrone
CACIDI 2018
Industria 4.0
Lic. Pablo A. Rever
CACIDI 2018
LabOSat
Lic. Gabriel Sanca
CACIDI 2018
En el mundo del BlockChain
Lic. Esteban Abete
CACIDI 2018
Shaders graficos y compilacion
Dr. Diego Novillo
CACIDI 2018
¿Qué son los datos y cómo administrarlos?
Mg. Cecilia Ana Ruz

Reuniones SDN – Febrero 2018 – 2da Reunión

En la reunión de la fecha se hizo una puesta en común de los siguientes temas:

1. Se comunicó al grupo la solicitud de presupuestos para adquirir el servidor de apoyo para el laboratorio 3.

2. Se establecieron y discutrieron los deadlines correspondientes a la entrega de informes, presentación de borradores de papers CACIDI 2018 y se establecieron las comisiones responsables para la redacción y presentación de los mismos.

3. Se analizaron los comentarios realizados por el ingeniero Luis Marrone(UNLP) sobre la secuencia de investigación apropiada sobre los distintos tópicos de este grupo.

4. Se analizaron las presentaciones a realizar para el CACIDI 2018.

5. Se evaluaron materiales y presupuestos necesarios para los próximos pasos a seguir sobre el tema en cuestión.

Reuniones SDN – Enero 2018

Hasta el momento en el mes de enero nos juntamos en dos fechas los integrantes del grupo de SDN: Matías Damico (representando a José Cahuana), Deolindo Zanuttini, Daniel Priano, María Claudia Abeledo (representando a Joaquin Gonzalez), Aldana Lacapmesure, Christian Andres, Matías Marsicano, Alejandro Dini y Pedro Iriso.

Se llego a lo siguiente:

  1. Se define realizar y documentar un marco teórico apropiado con bibliografía y documentos en línea de sitios académicos reconocidos (IEEE, Stanford University, entre otros).
  2. Se establece la fecha del 30-04 para la entrega del informe.
  3. Se planificó realizar un escenario en el laboratorio de redes de la UNSAM, sobre los servidores con los que se cuenta y eventualmente, otro de mayor capacidad que pueda adquirirse con fondos de UNSAM. En este escenario se analizarán sobre redes instaladas en las diferentes VM, los elementos que definen una SDN.
  4. Fechas de reunión: 04-01-18, 06-01-2018,09-01-2018

Reuniones SDN – Febrero 2018

En la primer reunión del mes de Febrero, nos juntamos los integrantes del grupo de SDN: Matías Damico, José Cahuana, Deolindo Zanuttini, Daniel Priano, María Claudia Abeledo, Joaquin Gonzalez, Aldana Lacapmesure, Christian Andres, Matías Marsicano, Alejandro Dini y Pedro Iriso.

Estuvimos trabajando en lo siguiente:

  1. Se repasaron contenidos y se investigó nuevos conceptos discutidos entre los integrantes del equipo.
  2. Se propuso una idea en común para investigar acerca de la comunicación por flujos y poder llevarla a la practica para obtener resultados.
  3. Se propuso la compra de un servidor para los laboratorios ante las autoridades de la UNSAM.
  4. Se intercambió información en videos y libros para profundizar los conocimientos que ya se habían obtenido y así poder fortalecerlos.
  5. Se analizaron los conceptos, licencias de software libre OpenFlow y OpenDaylight y CORP.