Mes: octubre 2017
Filtrar por direccion MAC. Primera Aproximacion.
La primera aproximación para filtrar por MAC utilizando un controlador SDN fue utilizando a Ryu como controlador. Mediante el siguiente script que se encuentra debajo.
En este comienzo lo que se realizo fue pasarle una dirección, como por ejemplo la “00:00:00:00:00:02” y tanto los paquetes de origen como de destinatario a esa MAC se ven descartados.
El resultado de esto, probandolo con una topologia de 5 switch y 5 host fue la siguiente:
ANDADOR – CODE v2.0
// Adafruit NeoPixel - Version: Latest #include <Adafruit_NeoPixel.h> #define trig1Pin 2 #define trig2Pin 4 #define echo1Pin 3 #define echo2Pin 5 #define PIN 14 #define LED_COUNT 3 Adafruit_NeoPixel leds = Adafruit_NeoPixel(LED_COUNT, PIN, NEO_GRB + NEO_KHZ800); void setup() { Serial.begin (9600); pinMode(trig1Pin, OUTPUT); pinMode(trig2Pin, OUTPUT); pinMode(echo1Pin, INPUT); pinMode(echo2Pin, INPUT); leds.begin(); } void loop() { long distance1, distance2, color1, color2; distance1=callSensor(trig1Pin, echo1Pin); distance2=callSensor(trig2Pin, echo2Pin); color1 = checkDistance(distance1); color2 = checkDistance(distance2); if(color1 > color2) { pixelColor(color1); } else { pixelColor(color2); } Serial.print(distance1); Serial.println(" cm"); Serial.println(" - "); Serial.print(distance2); Serial.println(" cm"); delay(500); } int callSensor(int writePin, int readPin){ long duration, distance; digitalWrite(writePin, LOW);// Added this line delayMicroseconds(10); // Added this line digitalWrite(writePin, HIGH); delayMicroseconds(10); digitalWrite(writePin, LOW); duration = pulseIn(readPin, HIGH); distance = (duration/2) / 29.1; return distance; } long checkDistance(long distance){ long color; switch (distance) { case 1 ... 40: color = 0xFF0000; break; case 41 ... 70: color = 0xFFFB00; break; default: color = 00000000; break; } return color; } void pixelColor(long color){ int i; for(int i=0;i<LED_COUNT;i++){ leds.setPixelColor(i, color); leds.show(); delay(50); } }
ANDADOR – Code v1.0
// Versión 1.0 - 20170828 #include <Adafruit_NeoPixel.h> #define trig1Pin 2 #define trig2Pin 4 #define echo1Pin 3 #define echo2Pin 5 #define PIN 14 #define LED_COUNT 3 Adafruit_NeoPixel leds = Adafruit_NeoPixel(LED_COUNT, PIN, NEO_GRB + NEO_KHZ800); void setup() { //Serial.begin (9600); pinMode(trig1Pin, OUTPUT); pinMode(trig2Pin, OUTPUT); pinMode(echo1Pin, INPUT); pinMode(echo2Pin, INPUT); leds.begin(); } void loop() { long distance1, distance2, color1, color2; distance1=callSensor(trig1Pin, echo1Pin); distance2=callSensor(trig2Pin, echo2Pin); color1 = checkDistance(distance1); color2 = checkDistance(distance2); if(color1 > color2) { pixelColor(color1); } else { pixelColor(color2); } /* Serial.print(distance1); Serial.println(" cm"); Serial.println(" - "); Serial.print(distance2); Serial.println(" cm"); */ delay(600); } int callSensor(int writePin, int readPin){ long duration, distance; digitalWrite(writePin, LOW);// Added this line delayMicroseconds(2); // Added this line digitalWrite(writePin, HIGH); delayMicroseconds(20); digitalWrite(writePin, LOW); duration = pulseIn(readPin, HIGH); distance = (duration/2) / 29.1; return distance; } long checkDistance(long distance){ long color; switch (distance) { case 1 ... 25: color = 0xFF0000; break; case 26 ... 50: color = 0xFFFB00; break; default: color = 00000000; break; } return color; } void pixelColor(long color){ int i; for(int i=0;i<LED_COUNT;i++){ leds.setPixelColor(i, color); leds.show(); delay(50); } }
ANDADOR – Andador con Detección de Obstáculos por Ultrasonido
Equipo:
- Nicolas Saban
- Esteban Buniak
- Fabiana Fulgenzi
- Martin Gonzalez Perna
Agosto 2017
Jueves 10
Primera toma de contacto con el Andador: constaba de un Arduino Nano v2.2 genérico con cables de múltiples colores soldados directo a sus pines de salida. Muchos cables estaban desoldados y los pines estaban bastante oxidados. Además, la placa que portaba al Arduino había sido lavada con solvente (por razones desconocidas), destruyendo casi todas sus pistas.
El cableado pasaba por dentro de la estructura del Andador, pero en muchos casos los colores de los cables de salida no coincidían con los que entraban en la tubería.
Los sensores ultrasónicos SH-04 estaban apenas soldados, así como los motores vibradores. Los pines de los leds se encontraban firmes, pero no fue posible rastrear cuáles eran los cables que salían del Arduino que correspondían.
Luego de relevar el estado general, el equipo decidió llevar a cabo modificaciones sobre la infraestructura del desarrollo a fin de optimizar su funcionamiento y el mantenimiento general.
El cambio más significativo fue el reemplazo completo del cableado general, así como modificar la fuente de alimentación del prototipo (que originalmente pensaba ser mediante pilas) a un modelo tipo powerbank de 5v del tipo que habitualmente se usa para cargar teléfonos celulares.
Se definió que la nueva instalación eléctrica debía estar dispuesta por fuera de la estructura, a fin de poder llevar a cabo modificaciones de forma más cómoda, además de considerar escenarios de mantenimiento o reparación del prototipo.
Jueves 17
Se completó el desarme y se preparó un nuevo cableado con cables rezagos de cable Ethernet. El testeo de los sensores fue exitoso, no así el test de uno de los motores vibradores: con 5v directo no reaccionó. Se imprimieron en 3D carcasa a los SH-04 con posibilidad de regular el ángulo de ataque.
El Nano v2.2 daba la respuesta eléctrica que ordenaba el software cargado; sin embargo, la placa soporte donde estaba soldado estaba en pésimas condiciones. Intentamos sin éxito soldar sobre la misma, pero la inexistencia de pistas fue un conflicto insalvable, por lo que se deshicieron las soldaduras y Esteban Buniak se ofreció a retirar el Arduino de su placa.
A fin de salvar el problema con el Arduino, se armó una estructura de prueba con un Arduino Pro Micro de reemplazo. Estructurado sobre una protoboard y con un cableado modelo, se diagramó la estructura básica del nuevo código. Además, se verificó que el WS2812 (led RGB) precisa una galería específica de Adafruit (library Adafruit_Neopixel.h) por lo que sobre el ámbito de pruebas se cargó un programa básico de testeo de la galería y se verificó que los leds funcionan correctamente, además de corroborar que si son instalados en serie pueden comportarse como un array de leds. Se imprimieron en 3D monturas para los tres WS2812.
El versionado de código no se logró documentar.
Jueves 24
Con la instalación nueva con cables Ethernet se procedió a la reconexión con el Arduino Nano desoldado. Sin embargo, los sensores repentinamente dejaron de funcionar correctamente. Se revisó la instalación eléctrica completa, lo cual develó un nuevo conflicto: El uso de cables Ethernet se mostró como una decisión poco práctica para el prototipo y el quebradizo alambre interno generó múltiples conflictos en la instalación provisoria.
Luego de múltiples intentos y revisiones de cableado, logramos aislar el problema: los pines del Arduino Nano fallaban en entregar los pulsos que el software usaba para las mediciones.
Se realizó un programa sketch rápido iterando entre todos los pines, cambiando los valores de output a high (lo que provoca que los pines digitales entreguen 5v sostenidos). Las mediciones dieron como resultado que varios pares de pines no entregaban más de 1.5v, con intermitentes caídas hasta 1.3v. Verificamos que varios pines del Nano se encontraban muy dañados; posiblemente el paso del tiempo no le permitió resistir el stress recibido durante el desoldado de la placa original sobre la que estaba montado. Restará revisar si una limpieza profunda o un cambio de pines permite el salvado del controlador.
Se procedió a realizar una nueva instalación eléctrica, ésta vez usando cables multifilares, fichas housing dupont para las conexiones, el Arduino Micro Pro usado en los testeos como microcontrolador y una protoboard para el montaje de todas las conexiones, priorizando la modularidad para la instalación y reemplazo de piezas.
Además, se realiza una refactorizacion sobre el código del testeo del 17-8 a fin de proveer al programa de mayor cohesión. El código (Andador-code v1.0) se encuentra en la entrada correspondiente.
El diagramado del circuito se corresponde con el diagrama v1.0:
Jueves 31
Testeamos el nuevo Layout sobre el andador. Además de notar que los cables tenían una extensión algo excesiva, no hubo mayores inconvenientes en la presentación. Sin embargo, muchos de los pines no conectaban a fondo, propio de la arquitectura de pines y la ubicación del cableado respecto a los sensores. En varias oportunidades, los pines de los sensores ultrasónicos se desprendían o entraban en falso contacto, generando errores en las mediciones o desconexiones repentinas.
En los primeros momentos el sistema parecía funcionar exitosamente, sin embargo, se empezó a detectar problemas en las mediciones de los sensores de proximidad, que repentinamente comenzaban a disparar spikes o picos en las distancias de las mediciones, entregando datos aberrantes de forma aparentemente aleatoria.
Empezamos a monitorear qué sucedía sosteniendo los pines de conexión y las mediciones tendían estabilizarse, por lo que se procedió directamente a eliminar las fichas y soldar los sensores de forma directa al circuito.
Al energizar nuevamente el circuito, las deficiencias en las mediciones empeoraron, siendo prácticamente imposible devolver al andador a un modo operativo predecible debido a que el ruido introducido por las mediciones arruinaba el funcionamiento entero.
Se intentó entonces anular por software las mediciones aberrantes, pero éstas eran tantas, que el prototipo quedaba inútil, procesando y eliminando mediciones el 70% del tiempo funcional.
Finalmente, definimos reemplazar las soldaduras por pines dupont, reemplazar los cables que podrían estar comprometiendo el funcionamiento del prototipo e investigar con mayor profundidad la documentación relativa a los sensores SH-04 y los WS2812.
Septiembre 2017
Jueves 7
La documentación relativa a los WS2812 otorgada por Sparkfun nos ayudó a dar con la clave respecto a las mediciones aberrantes: el sistema de array de LEDs genera al momento de encenderse un pico de consumo mucho mayor del que era capaz de otorgar el Arduino (que estaba alimentando a todo el prototipo), generando que todo el sistema sufra de inanición eléctrica, y como consecuencia, provocando errores en las mediciones.
Para intentar saltar la limitación, procedimos a un cambio en la arquitectura del sistema, introduciendo una fuente de alimentación externa: Un powerbank que alimentara las lineas de corriente de la protoboard sobre la que se monta el circuito de conexiones primario.
Sin embargo, las mediciones desmesuradas seguían provocándose, principalmente sobre uno de los SH-04, por lo que se definió el reemplazo del sensor por un SRF-05. Curiosamente, las mediciones entregadas por este último se mantuvieron asombrosamente estables y casi sin aberrantes. Además se revisaron los ciclos de llamados a los sensores desde el software para intentar eliminar la posibilidad de overlapping entre pulsos de ultrasonidos (que un sensor tome la medición del otro).
Finalmente, se introdujo una resistencia de 3k Ohms en el pin data y un capacitor de 330F entre los pines VCC y GND de alimentación del circuito al array de Neopixels, a fin de suavizar todo lo posible el pico de consumo de los leds; la medida fue exitosa y el SRF-05 no volvió a dar errores de mediciones. Sin embargo, el segundo SH-04 si, por lo que se definió finalmente el reemplazo de ambos SH-04 por SRF-05.
Además, se definió descartar la introducción de motores vibradores en los manillares del andador, considerando que pueden provocar reacciones inesperadas en los usuarios, así como complicaciones innecesarias respecto al consumo eléctrico del prototipo.
Jueves 14
La nueva configuración no pasó los testeos sobre el prototipo. Las fichas, la disposición de los sensores y el cableado no contribuyen a la correcta medición, introduciendo exceso de ruido el sistema. También hay problemas con el cableado a los LEDs.
Entonces definimos retornar al modelo original, con sensores SH-04, revisando fuertemente las conexiones y los pines de conexión.
Revisado el sistema, fijando los sensores sobre el chasis del prototipo y regulando los ángulos, finalmente el andador funciona con buenas mediciones y el comportamiento respeta al programado.
Sin embargo, se descubrieron algunos puntos ciegos en el sistema y las mediciones sobre telas tienden a tener cierto delay.
Quedan por revisar detalles sobre el código, optimizar el uso de la energía y llevar a cabo una revisión completa del diseño y disposición de los elementos, a fin de mejorar la practicidad y estética del prototipo. El código (Andador-code v2.0) se encuentra en la entrada correspondiente.
Pruebas con OVS y Linux namespaces
Pruebas con OVS y Linux namespaces
Inspeccionamos el funcionamiento de Mininet al ejecutar sus tareas de forma manual.
Creamos los network namespaces que simulan los hosts.
Usando virtual ethernet conectamos los hosts a un switch OVS.
# crear namespaces
ip netns add red
ip netns add green
# crear switch
ovs-vsctl add-br OVS1
# crear interface virtual ethernet
ip link add eth0-r type veth peer name veth-r
# conectamos un extremo al namspace
ip link set eth0-r netns red
# conectamos el otro extremo al switch
ovs-vsctl add-port OVS1 veth-r
# repetimos para el otro namespace
ip link add eth0-g type veth peer name veth-g
ip link set eth0-g netns green
ovs-vsctl add-port OVS1 veth-g
# Levantar interfaces y asignar direcciones
ip link set veth-r up
ip netns exec red ip link set dev lo up
ip netns exec red ip link set dev eth0-r up
ip netns exec red ip address add 10.0.0.1/24 dev eth0-r
ip link set dev veth-g up
ip netns exec green ip link set dev lo up
ip netns exec green ip link set dev eth0-g up
ip netns exec green ip address add 10.0.0.2/24 dev eth0-g
Participacion en comunidad de desarrollo de Openstack
Para incorporarse en la lista de correo de Openstack de desarrollo debemos ingresar a la pagina http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-
- en la sección Subscribing to OpenStack-dev tenemos que ingresar los datos solicitados y luego hacer click en el botón Suscribe
- revisamos la casilla de mail ingresada en el formulario y aceptamos la inscripción accediendo a la dirección que nos indica en el mail y haciendo click en el botón Suscribe
- la lista nos enviará un mail indicando que ingresamos a la lista de correo
- para editar las opciones de suscripcion de la lista debemos ingresar a la direccion que nos aparece en el mail de bienvenida a la lista que se acemeja a esta http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev/
- una vez que se accede a la página ingresar la contraseña que eligio en la pagina de suscripcion
- cuando accedió a la página para modificar las opciones debe tildar la opción Neutron (Details) y luego hacer click en el botón “Submit My Changes”
Otro lugar en donde se puede obtener información es:
Existe un grupo de usuarios de Openstack en Argentina en donde se realizan encuentros donde se dictan charlas sobre esta tecnología. La página del grupo es : https://www.meetup.com/es-ES/openstack-argentina/
Primeros pasos con Switch OVS
Luego de una lectura a la documentación de Open vSwitch y a diferentes tutoriales que explican su funcionamiento, se pueden seguir los pasos para virtualizar diferentes interfaces de red que se interconectarán entre sí a través de un switch (de forma similar a Mininet, pero directamente a través de Open vSwitch).
Siguiendo los pasos en el archivo antes mencionado, se puede obtener una topología como la siguiente y lograr conectividad entre los namespace rojo y verde.
El siguiente paso es implementar reglas de filtrado por MAC en el Switch OVS
EDIT: se publicó un script que ejecuta paso a paso el desarrollo de este experimento aquí
Resumen de primeros avances
Dado el retraso en publicar los informes de avance, sirva este primero como resumen del progreso hasta ahora.
Comenzamos junto con todo el grupo instalando el entorno en máquinas virtuales con Ubuntu 16.04 a través de VirtualBox. A lo largo de distintos ensayos fuimos conociendo las herramientas y familiarizándonos, lo que concluyó con la confección del informe Nº1, donde a través de Mininet y RYU especificamos una topología y configuramos los switches bajo distintos comportamientos.
Luego nos dividimos en diferentes grupos, y a partir de eso nos concentraremos en Open vSwitch.
Grupos de trabajo y áreas de desarrollo SDN & NFV
Quedaron definidas los siguientes grupos de trabajo y desarrollo hasta el momento:
> Grupo A
>> Area de desarrollo: Gestión y virtualización de infraestructura
>> Herramientas a utilizar: OpenStack
>> Funciones: Conocer al detalle las funcionalidades de las herramientas / Participar en las comunidades de desarrollo / Interactuar con los demás grupos para lograr el objetivo final propuesto / Postear los avances semanalmente
>> Referente Grupo: Christian Andrés
>> Integrantes: Christian Andrés
> Grupo B
>> Area de desarrollo: Plano de Control / Controladores
>> Herramientas a utilizar: Ryu (Python) / OpenDaylight (Java)
>> Funciones: Conocer al detalle las funcionalidades de las herramientas / Participar en las comunidades de desarrollo / Interactuar con los demás grupos para lograr el objetivo final propuesto / Postear los avances semanalmente
>> Referente Grupo: Matías D’amico
>> Integrantes: Matías D’amico / José Cahuana / Aldana Lacapmesure
> Grupo C
>> Area de desarrollo: Protocolos de control / Plano de datos (Switch virtual)
>> Herramientas a utilizar: OpenvSwitch
>> Funciones: Conocer al detalle las funcionalidades de las herramientas / Participar en las comunidades de desarrollo / Interactuar con los demás grupos para lograr el objetivo final propuesto / Postear los avances semanalmente
>> Referente Grupo: Nicolás Pucci
>> Integrantes: Nicolás Pucci / Alejandro Dini
> Colaboradores
>> Función: Recopilación y documentación / Armado de informes
>> Integrantes: Jonathan Rómbola / Ana Gisel Padilla / Leonardo Galarza
Propuestas y objetivos de trabajo para SDN & NFV
Líneas de trabajo para ciencia aplicada:
1) Desarrollo de aplicaciones que hagan uso de plataformas existentes
>> Objetivo 1: Integrar aplicaciones sobre el controlador mediante el uso de API
>> Objetivo 2: Integrar aplicaciones sobre el gestor de infraestructura virtual mediante el uso de API
Posibles aplicaciones que se pueden desarrollar:
> Firewall
> Balanceador de carga
> NAT
> Control de sesiones
> Auto-provisioning
> Reutilización de ancho de banda
> Restauración de servicios por redes alternativas
2) Integración de plataformas de software existentes (Switch/Router + Controlador + Cloud)
>> Plano de datos –> Switches/Router: OpenvSwitch
>> Plano de control –> Controladores: OpenDaylight, Ryu, ONOS, Floodlight
>> Gestión de infraestructura virtual –> OpenStack
>>> Objetivo 1: Integrar Mininet + OpenDaylight
>>> Objetivo 2: Integrar OpenDaylight + OpenStack
>>> Objetivo 3: Integrar Mininet + OpenDaylight + OpenStack
>>> Objetivo 4: Integrar Dispositivos embebidos (TP-LINK + OpenWRT + OpenvSwitch) + Mininet + OpenDaylight + OpenStack
3) Desarrollo de hardware para SDN (CPE, switch, router)
Líneas de trabajo para investigación:
1) Adaptación de protocolos para que trabajen sobre SDN
2) Mejora de métodos de trabajo/algoritmos para las aplicaciones que se desarrollen
3) Proponer arquitecturas para extender el uso de SDN a otros tipos de estructura de redes
4) Participación activa en foros de desarrollo existente
Firewall con Ryu
Se utiliza la aplicacion de Ryu “rest_firewall.py” y el programa postman para manejar comandos rest.
Se crea una topologia de un switch y tres host.
“sudo mn –topo single,3 –controller remote –mac”
Luego se configura la versión de openflow que se va a utilizar.
“ovs-vsctl set Bridge s1 protocols=OpenFlow13”
Al comenzar el firewall bloquea toda comunicación y desactiva el switch.
Podemos activar el switch mediante:
“http://localhost:8080/firewall/module/enable/0000000000000001”
El estado se puede ver:
“http://localhost:8080/firewall/module/status”
Luego se añaden las reglas para permitir la conexión entre host haciendo un post:
“http://localhost:8080/firewall/rules/0000000000000001”
Pasandole por parámetros en la casilla “body” el parámetro de origen, destino y protocolo:
{“nw_src”: “10.0.0.1/32”, “nw_dst”: “10.0.0.2/32”, “nw_proto”: “ICMP”}
La regla debe ser bidireccional, se debe crear hacia ambas direcciones.
{“nw_src”: “10.0.0.1/32”, “nw_dst”: “10.0.0.2/32”, “nw_proto”: “ICMP”}
Con esto previo, se crearon dos reglas, uno para permitir ICMP de 10.0.0.1 a 10.0.0.2 y de 10.0.0.2 a 10.0.0.1.
Luego podemos probar que esto funciona, viendo no bloqueamos la comunicación entre el host 1 y el 2 pero no existe ninguna regla con el host 3 entonces no puede llegar hacia el.
Para eliminar una regla se puede hacer un delete:
“http://localhost:8080/firewall/rules/0000000000000001”
Agregándole en body, el ID de la regla:
{“rule_id”: “1”}
{“rule_id”: “2”}
Routeo dinámico en SDN
Luego de realizar diversas pruebas con las implementaciones RouteFlow(https://github.com/CPqD/RouteFlow/wiki/Tutorial-2:-rftest2) y pwospf (https://github.com/mininet/mininet/wiki/Pee-Wee-OSPF-(PWOSPF)), las cuales se encuentran deprecadas y no se ha logrado resultados satisfactorios. Hemos logrado realizar la prueba que funciono tal cual lo esperado utilizando el protocolo OSPF en un lado de la red y BGP en otro lado de la red (https://github.com/edwinsc/mininet_ospf_bgp), el diagrama de red es el siguiente :
