Universidad de Extremadura

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Universidad de Extremadura"

Transcripción

1 Universidad de Extremadura Centro Universitario de Mérida Grado en Ingeniería en Telemática Trabajo Fin de Grado ANÁLISIS Y EVALUACIÓN DE LAS REDES DEFINIDAS POR SOFTWARE Autor/a: Pablo Murillo Nogales Mérida, Julio de 2015

2

3 Universidad de Extremadura Centro Universitario de Mérida Grado en Ingeniería en Telemática Trabajo Fin de Grado ANÁLISIS Y EVALUACIÓN DE LAS REDES DEFINIDAS POR SOFTWARE Autor/a: Pablo Murillo Nogales Fdo: Director/a: Javier Domingo Carmona Murillo Fdo:

4

5 Resumen Software-Defined Networking (o Redes Definidas por Software) es un nuevo paradigma que tiene como objetivo simplificar la creación y gestión de redes de ordenadores. El desacoplamiento entre el control de la red y el plano de reenvío propuesto por esta arquitectura permite el control de todo el comportamiento de la red mediante un elemento lógico centralizado, llamado controlador. Esta separación de los planos abre la puerta a la virtualización de redes, proporcionando a los usuarios una abstracción lógica de los recursos de red subyacentes. La iniciativa Open Networking Foundation (ONF), está desarrollando estándares abiertos que permitan alcanzar los retos planteados por SDN. El resultado es lograr una arquitectura que permita a los administradores de red tener un control total en el funcionamiento de la red a través del despliegue de software que controle y automatice el comportamiento de la misma. La ONF ya ofrece el estándar OpenFlow, que permite la programación remota del plano de control. Este es el primer estándar SDN y un elemento vital de una arquitectura de red definida por software. En este trabajo analizaremos las SDN y el protocolo OpenFlow y veremos algunas de las diferentes alternativas de controladores para terminar centrándonos en OpenDaylight. Además procederemos a desplegar una red de ejemplo mediante la herramienta Mininet que permite simular un entorno SDN. Después se ha realizado un caso práctico para comprobar de forma más concreta como programar un controlador y en definitiva poder manejar toda la red. Finalmente se han realizado algunas pruebas con el fin de analizar y mejorar el rendimiento energético de una red SDN. Como resultado se obtiene que efectivamente el consumo energético mejora, aunque en contra, la carga total de la red aumenta. 5

6 6

7 Abstract Lately, the emerging paradigm of Software-Defined Networking has grown in presence and claims to simplify future networking. The decoupling of network control and forwarding plane proposed by this architecture allows the control of the entire network behavior by means of a logically centralized software program (controller). Such separation of planes opens the way to Network Virtualization, which provides users a logical abstraction of underlying network resources. Open Networking Foundation (ONF) is a user-driven organization dedicated to the promotion and adoption of Software-Defined Networking (SDN) through open standards development. Thus, network administrators, will be able to program and control the forwarding plane of such networks in a new way. In this work we analyze the SDN and the OpenFlow protocol and we see some of the different alternative controllers, and finally, we focus on OpenDaylight. Furthermore we proceed to create a sample network using Mininet to simulate a SDN environment. Finally a case study is performed to check more specifically how to program a controller and ultimately to manage the entire network. Finally, some tests be performed in order to analyze and improve the energy performance of a SDN network. Obtained results show that our proposal improves the energy consumption, although the network load is increased. 7

8

9 Índice general 1. Introducción Antecedentes Objetivos Planificación Estructura del documento Software Defined Networking Introducción Concepto de SDN SDN y virtualización Beneficios del SDN Usos de SDN OpenFlow Protocolo OpenFlow Funcionamiento de OpenFlow Flujos Tablas de flujos Instructions Counters Mensajes del protocolo OpenFlow Matching Probando OpenFlow Explicación teórica Software utilizado Controladores OpenDaylight Ryu Floodlight NOX/POX Mininet Ventajas e inconvenientes de Mininet i

10 Índice general vswitch Wireshark Iperf Eclipse Maven Uso del software Mininet Wireshark OpenDaylight Caso práctico: Mejora de la eficiencia energética en una red SDN Explicación teórica Desarrollo del código: Java Desarrollo del código: Maven Desarrollo del código: Python Funcionamiento Configuración módulo flowapp Iniciando OpenDaylight Iniciando Mininet Resultados Conclusiones y trabajo futuro Conclusiones Trabajo futuro Agradecimientos 75 Bibliografía 77 ii

11 Índice de figuras 3.1. Esquema Openflow Proceso de matching Topología PACKET_IN PACKET_OUT a FLOW_MOD a PACKET_OUT b FLOW_MOD b Ultimos paquetes Wireshark Packet-in y Flow-mod OpenDaylight Helium Floodligh Mininet VM ifconfig mininet> Topología simple Mininet Topología con MiniEdit Controlador remoto MiniEdit Activar CLI MiniEdit Ventana de Wireshark Controlador OpenDaylight iniciándose Topología en malla Topología en anillo Topología en árbol dependencies Compilar con Maven Código python iperfudp OpenDaylight configuración y monitor Topología en malla Topología en anillo Topología árbol

12 Índice de figuras 2

13 Índice de tablas 1.1. Metodología del trabajo Principales componentes de una entrada en una tabla de flujo Lista requerida de contadores para usar en mensajes de estadísticas Campos de los paquetes usados para matching Bundles importantes de OpenDaylight AD-SAL vs MD-SAL

14 Índice de tablas 4

15 1 Introducción 1.1. Antecedentes La idea de programar redes no es nueva, según [1] hay varias contribuciones anteriores a SDN. Una de ellas es SOFTNET [2], allá por principios de los 80, una red multisalto, semejante a las a las actuales WSN (Wireless Sensor Networks) cuya innovación fue que en el campo de datos de cada paquete se incluían comandos que los nodos iban ejecutando a medida que los iban recibiendo. De esta manera, la red podía irse modificando de forma dinámica y en tiempo real. Fue un intento de definir una red auto-organizable destinada a permitir la experimentación y la innovación con diferentes protocolos. No hubo desarrollo posterior, pero su idea fue el embrión de las posteriores Active Networks [3]. Las Active Networks presentaban una arquitectura consistente en llevar embebido en los paquetes pequeños programas que podían ser ejecutados por los nodos que éstos atraviesan. Esto hacía posible que los switches y routers de la red procesaran los paquetes de datos, haciéndoles partícipes de los mensajes y no solo meros espectadores que se limitaban a enviar mensajes de un puerto a otro, de una forma pasiva. De ahí el nombre de Active Networks. El área de Active Networks fue una tendencia en investigación hace tiempo, aunque últimamente ha decaído. Tanto SOFTNET como Active Networks concibieron una red innovadora, dinámica y partícipe de los datos que transportaban. El mecanismo era básicamente el mismo: añadir líneas de código a los paquetes de datos para que los nodos intermedios las ejecutarán. No incorporaban un elemento software como control de los elementos de conmutación, como sí hace la filosofía SDN. En 2007, un grupo de trabajo de la Universidad de Standford formado por los profesores Nick McKeown, Scott Shenker y el estudiante de doctorado Martín Casado desarrollaron OpenFlow y fundaron Nicira, una compañía de virtualización de redes. Es a partir de este momento donde se sitúa el nacimiento de SDN. En 2011, Scott Shenker y Nick McKeown fundaron la Open Networking Foundation (ONF), organización que buscaba fomentar el uso de OpenFlow, la creación de 5

16 1 Introducción estándares y la implantación de SDN más allá de las universidades. En julio de 2012 VmWare, una de las compañías líderes en virtualización de servidores, dio un paso hacia la incorporación de la virtualización de redes en su gama de productos y compró Nicira por 1260 millones de dólares. Martín Casado pasó a ser el "arquitect networking" en jefe de VMware [4] Objetivos Los objetivos del trabajo eran el diseño, desarrollo y prueba de escenarios basados en máquinas virtuales que permitieran evaluar las nuevas arquitecturas de red basadas en software (Software Defined Networks o SDN). Se estudiaron los componentes básicos utilizados en SDN: Protocolo OpenFlow. Emuladores de red con soporte OpenFlow como Mininet. Entornos como OpenDayLight. Partiendo de estos componentes, se crearon escenarios que combinaban estas plataformas con el objetivo de detectar los beneficios que puede aportar el paradigma SDN frente a la gestión tradicional de la red. Además se ha desarrollado una aplicación con la que intentar mejorar la eficiencia energética de las redes usando tecnologías SDN Planificación Metodología de trabajo (ver tabla 1.1): 1. Análisis y estudio de los antecedentes de SDN y OpenFlow. 2. Análisis de los elementos que componen la red SDN y Openflow. 3. Virtualización de agentes de red. Mininet. 4. Despliegue y análisis de las plataformas OpenDayLight. 5. Desarrollo de aplicación bajo OpenDaylight y estudio de su comportamiento. 6

17 Febrero Marzo Abril Mayo Junio Tarea 1 X Tarea 2 X Tarea 3 X Tarea 4 X X Tarea 5 X X Tabla 1.1: Metodología del trabajo 1.4 Estructura del documento 1.4. Estructura del documento Este trabajo aborda los temas antes mencionados a partir de una definición más amplia de las tecnologías y su introducción, seguido de la descripción del diseño de la aplicación propuesta y del análisis de sus mediciones. El trabajo se ha estructurado en cinco capítulos principales de la siguiente manera: El Capítulo 2 presenta las Redes Definidas por Software. Se tratan de explicar como concepto y sus relaciones con la virtualización. Además se aportan una serie de beneficios de este tipo de redes. Por ultimo se explican algunos usos que pueden tener las SDN. En el Capítulo 3 se realiza un análisis del protocolo OpenFlow. Se explica el funcionamiento de las distintas partes que lo componen y finalmente, se simula un caso práctico para asentar la concepción de como funciona el protocolo. El Capítulo 4 describe el software utilizado. Primeramente se exponen algunos controladores compatibles con OpenFlow y se hace un inciso en el controlador OpenDaylight que es el que se usará posteriormente para realización de la aplicación práctica. También se prestará atención al software emulador de redes SDN Mininet. Por ultimo se harán algunos ejemplos sencillos que muestran como ejecutar estas aplicaciones. En el Capítulo 5 se mostrará como se ha desarrolado la aplicación descrita anteriormente además de su funcionamiento y las pruebas realizadas para probar dicha aplicación. Finalmente en el Capítulo 6 se harán las conclusiones pertinentes y una serie de posibles trabajos futuros a desarrollar relacionados con las SDN. 7

18 1 Introducción 8

19 2 Software Defined Networking 2.1. Introducción El SDN (Software Defined Networking) es una técnica emergente que concentra las funciones de control de la red en elementos software. Explicaremos el concepto de SDN, su relación con las técnicas de virtualización y sus beneficios, explorando también el concepto de Network Functions Virtualization (NFV) [5] Concepto de SDN SDN es el acrónimo de Software Defined Networking, es decir, la implementación en software de algunas funciones de red. Para entender lo que SDN aporta, conviene primero repasar cuáles son las funciones de un router o un switch en una red, típicamente una red IP. Este tipo de equipos soportan dos funciones fundamentales: Una función de transporte: que se podría entender como su función primaria y que consiste, simplemente, en transportar datos a su destino. Para ello, estos equipos envían los paquetes de datos a dónde indiquen unas rutas previamente calculadas. Una función de control: que permite gestionar la función de transporte mediante otras dos subfunciones principales: Intercambiar información sobre conectividad con otros routers/switches. Calcular rutas con base en la información obtenida. En el networking tradicional tanto las funciones de control como las de transporte son ejecutadas de forma distribuida en todos los routers/switches de la red. SDN es un enfoque de networking que, por un lado, separa claramente las funciones transporte y de control y, por otro implementa la función de control con software (en lugar de hacerlo en hardware). Además, centraliza en un elemento, el controlador esa función de control. Resumimos pues los tres elementos que caracterizan al Software Defined Networking (SDN): 9

20 2 Software Defined Networking Separación clara entre las funciones de transporte y de control. Centralización de la función de control. Implementación de la función de control en software. El hecho de centralizar la función de control y de implementarla en software conlleva que la red se pueda programar mediante aplicaciones, lo que proporciona una enorme flexibilidad y facilidad de despliegue de funciones de red. Además, el controlador puede exponer interfaces de aplicación que facilitan la manipulación y gestión de la red [6] SDN y virtualización La virtualización es una técnica que pretende simular hardware y elementos de red mediante software. No es un concepto que provenga específicamente del mundo del networking sino que, de hecho, surgió más bien en el mundo de las Tecnologías de la información, de los grandes servidores de aplicaciones y los data centers. La virtualización abstrae las máquinas reales, el hardware real, en lo que se denomina la máquina virtual, esto es, una máquina ficticia implementada en software pero a la que se asigna memoria, espacio en disco, etc, como si de una máquina real se tratase. De esta forma las aplicaciones ven, por decirlo de alguna manera, una máquina adaptada a sus necesidades pero del alguna forma independiente del hardware real que la soporta. Para crear y gestionar esas máquinas virtuales se emplea un software que se denomina hypervisor. Aunque, ya en el campo del networking SDN y virtualización son conceptos diferentes, lo cierto es que en realidad aparecen muy unidos. Y lo hacen en el sentido de que las funciones de control centralizadas se suelen implementar como switches virtuales (es decir, la simulación de un switch en software) ejecutándose en máquinas virtuales alojadas sobre unos servidores físicos y gestionadas mediante un hypervisor. Un concepto relacionado con la virtualización y el SDN es el de virtualización de funciones de red (Network Functions Virtualization, NFV). Lo que significa este concepto es la centralización de funciones de red en servidores de propósito general virtualizados. Así, por ejemplo, se pueden centralizar funciones en el campo de la seguridad AAA (Authentication, Authorization and Accounting) Beneficios del SDN Qué aporta el SDN? Podríamos resumir los beneficios en los siguientes puntos: 10

21 2.5 Usos de SDN Elimina la lentitud en innovación propia del hardware permitiendo que ésta se produzca a la velocidad del software, especialmente en el plano de control. Optimiza el coste de hardware de networking. Implementación de la función de control en software. Simplifica el equipamiento de red Posibilita el uso de algoritmos más complejos y exigentes computacionalmente. Reduce la barrera de entrada para innovadores e investigadores. Reduce drásticamente los ciclos de vida de lanzamiento de servicios. Promueve la innovación en algoritmos de enrutamiento así como una mayor utilización de la capacidad de red Usos de SDN Las redes SDN tienen aplicaciones en una gran variedad de entornos de red. Separando los planos de control y de datos, las redes programables permiten un control personalizado y una oportunidad para de eliminar middleboxes y con ello simplificar el desarrollo y la implementación de nuevos servicios y protocolos. A continuación, se examinarán diferentes entornos para los que han sido propuestas o aplicadas soluciones SDN [5]. Redes empresariales: Una gestión adecuada es de vital importancia en entornos empresariales. Las redes SDN pueden ser usadas para manejar las políticas de red mediante programación. Las SDN pueden manejar funciones de middlebox como firewalls, NATs, balanceadores de carga o medidas de control de acceso. Data Centers: Un gran problema de los data centers, es el gran consumo energético que producen. Las redes SDN pueden permitir mejorar la eficiencia energética a través de métodos para usar solo una parte de la red, intentando que esto no repercuta en la eficiencia de la red. Más adelante nosotros también abordaremos este problema [7]. Redes ópticas: Manejar el trafico de datos mediante flujos, permite a las SDN y a OpenFlow en particular, soportar e integrar múltiples tipos de tecnologías de red. De acuerdo a el Optical Transport Working Group (OTWG) creado en 2013 por la Open Network Foundation (ONF), los beneficios de aplicar 11

22 2 Software Defined Networking SDN y el estándar OpenFlow en particular a las redes de transporte ópticas incluyen: mejora el control de red del transporte óptico y la flexibilidad en la administración, permitiendo la implementación de administración de terceros y control de sistemas, e implementando nuevos servicios de virtualización. Infraestructuras basadas en redes de acceso inalámbricas: Recientemente se está viendo un creciente interés académico y de la industria en para aplicar SDN a las redes móviles. La principal motivación detrás de esto es que SDN puede ayudar a los operadores móviles a simplificar la administración de sus redes y permitir nuevos servicios que soporten el crecimiento exponencial del tráfico previsto para las redes 5G [8]. Hogares y PYMES: Varios proyectos se han centrado en ver cómo las redes SDN podrían ser utilizadas en redes más pequeñas, tales como las que se encuentran en hogares o pequeñas empresas. Estos escenarios se están volviendo cada vez más complejos debido a la creciente disponibilidad de dispositivos de red de bajo coste y la necesidad de dispositivos más complicados de administrar y de mayor seguridad. GÈANT, la red científica europea, recientemente ha publicado entre sus futuras implantaciones, nuevas tecnologías para los entornos de red, entre ellas está la que tratamos en este documento, las redes SDN. Se pretende en un futuro, poder usar esta tecnología para controlar sus capas de transporte [9]. 12

23 3 OpenFlow Lo que propone OpenFlow [10] es una manera para que los investigadores puedan experimentar con protocolos en la redes que se usan a diario. Permite a los investigadores experimentar con switches de manera uniforme a la velocidad de la línea y con una densidad de puertos muy alta. Por otra parte, los fabricantes no tienen que exponer los procesos internos de sus switches. La propuesta de OpenFlow es muy clara, permitir que los investigadores puedan evaluar sus ideas en un entorno de trabajo real y ser un componente muy útil en los bancos de pruebas a gran escala Protocolo OpenFlow La mayoría de los switches Ethernet contienen tablas de flujos (Flow-Tables), la idea de OpenFlow es la posibilidad de modificar estas tablas de forma dinámica para implementar firewalls, NAT, QoS y recolectar estadísticas. Es posible experimentar con nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento, incluso alternativas para IP lo que supone una mayor innovación. El plano de datos no se vería afectado ya que está aislado y se procesaría de la misma manera que se ha estado realizando hasta hoy día. El cambio reside en el plano de control que se implementaría mediante OpenFlow. Los switch OpenFlow puede soportar diversas acciones, aunque es necesario tener una serie de características comunes a todos ellos. Un switch OpenFlow consiste en al menos tres partes (ver figura 3.1 [5]): Tabla de flujos: con una acción asociada a cada entrada de la tabla, indicando al switch como debe procesar ese flujo. Canal seguro que conecte el switch a un proceso de control remoto (controlador), permitiendo comandos y paquetes se puedan enviar entre el switch y el controlador usando el protocolo OpenFlow. Controlador: Un controlador añade y elimina entradas en la tabla de flujos. 13

24 3 OpenFlow Figura 3.1: Esquema Openflow Los switches tradicionales usan STP, SPB o TRILL para determinar cómo se reenvían los paquetes. OpenFlow traslada esta decisión de reenvío de los switches a los controladores, típicamente un servidor o una estación de trabajo. Una aplicación de gestión se ejecutará en las interfaces del controlador que une todos los switches en la red, facilitando la configuración de caminos de reenvío que utilizarán todo el ancho de banda disponible. La especificación define el protocolo entre el controlador y los switches y un conjunto de operaciones que se pueden realizar entre ellos Las instrucciones de reenvío se basan en el flujo, que consiste en que todos los paquetes comparten una serie de características comunes. Existen infinidad de parámetros que pueden especificarse para definir un flujo. Entre los posibles criterios podemos incluir los puertos por donde se reciben los paquetes cuando llegan, el puerto Ethernet de origen, la etiqueta VLAN, el destino Ethernet o el puerto IP y otro numero de características de los paquetes. Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna coincidencia con ninguna entrada de la tabla. El switch debería tener configurado un descartado de paquetes para el flujo que no haya sido definido, pero en la mayoría de los casos, el paquete será enviado al controlador. El controlador entonces define un nuevo flujo 14

25 3.2 Funcionamiento de OpenFlow para ese paquete y crea una o más entradas para la tabla. Éste envía la entrada o entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con las nuevas entradas creadas. SDN no es OpenFlow A menudo se apunta a Openflow como sinónimo de SDN, pero en realidad, es simplemente un elemento que forma parte de la arquitectura SDN. Openflow es un estándar abierto para un protocolo de comunicaciones que permite al plano de control interactuar con el plano de datos (Openflow, sin embargo, no es el único protocolo disponible o en desarrollo para SDN, aunque sí está convirtiéndose en el modelo estándar de implementación de una SDN Funcionamiento de OpenFlow Flujos Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna coincidencia con ninguna entrada de la tabla. El switch debería tener configurado un descartado de paquetes para el flujo que no haya sido definido, pero en la mayoría de los casos, el paquete será enviado al controlador. El controlador entonces define un nuevo flujo para ese paquete y crea una o más entradas para la tabla. Éste envía la entrada o entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con las nuevas entradas creadas. Cada flujo de entrada tiene asociada una acción simple. Las tres básicas son: 1. Reenvío de flujo de paquetes a un puerto o puertos dados. Esto permite que los paquetes ser encaminados a través de la red. En la mayoría de los switches sucede a la velocidad de la línea. 2. Encapsulación y reenvío este flujo de paquetes al controlador. El paquete será enviado al Canal Seguro, donde se encapsula y se envía al controlador. Típicamente se usa para el primer paquete en un nuevo flujo, para que el controlador pueda decidir si el flujo debe ser añadido a la tabla de flujos. También se puede usar para reenviar todos los paquetes al controlador para que sean procesados. 15

26 3 OpenFlow Match Fields Priority Counters Instructios Timeouts Cookie Tabla 3.1: Principales componentes de una entrada en una tabla de flujo 3. Descartar este flujo de paquetes. Puede ser usado por seguridad, para parar ataques de denegación de servicio o reducir el falso tráfico de descubrimiento broadcast desde los hosts finales Tablas de flujos Una tabla de flujo contiene una serie de entradas de flujo Cada entrada de la tabla de flujo (tabla ) contiene: match fields: Coincidencia. Este campo consiste en el puerto y la cabecera de paquete y opcionalmente metadatos especificados en una tabla anterior. priority: Prioridad del flujo. En el caso de que haya más de un flujo con el mismo match tendrá prioridad el flujo con el número de prioridad más alto. counters: Contadores que se actualizan cuando los paquetes coinciden (matched). instructions: Instrucciones que indican la acción que hará el paquete a procesar. timeouts: tiempos antes de que un flujo expire. Son dos: idle_time_out y hard_time_out. El primero hacer referencia al tiempo que un flujo estará sin usar. El segundo indica el tiempo real desde que se instaló el flujo. cookie: Valor que elige el controlador para filtrar las estadísticas, las modificaciones y el borrado de los flujos. No se usa: cuando se procesan los paquetes. Una entrada de la tabla de flujo es identificada por su "match fields" y prioridad Instructions Cada tabla de flujo contiene un set de instrucciones que se ejecutan cuando el paquete encuentra una coincidencia con la entrada. Estas instrucciones dan lugar a cambios en el paquete, en el conjunto de acciones y en el procesamiento. Un switch no tiene por qué soportar todos los tipos de instrucciones, solo las que se marcan como requeridas y son: Instrucción de escritura (Write-Actions action ): 16

27 3.2 Funcionamiento de OpenFlow Si la acción del tipo dado existe, se sobrescribe, si no, se añade. Ir a la tabla (Goto- Table next-table-id ): Indica la siguiente tabla en el procesado. El identificador de la siguiente tabla debe ser mayor que el de la actual. Las entradas del flujo de la última tabla no pueden incluir esta instrucción. Solo se permite una instrucción por cada tipo. Los switches OpenFlow con una tabla no lo necesitarán. Las instrucciones de la tabla de flujos modifican la acción asociada a cada paquete. Los paquetes empiezan a procesarse con un conjunto de acciones vacío. Las acciones pueden especificar que el paquete que se va a reenviar a través de un puerto específico, modificar el TTL, VLAN, etiqueta MPLS o la QoS. Además, una instrucción puede especificar un identificador de grupo. Se pueden definir en el switch mediante entradas en la tabla de grupo Las instrucciones de la primera tabla deberán realizar una acción en el paquete o añadir acciones que se realizarán después. Las instrucciones asimismo, deberán permitir que el procesado de paquetes continúe comparándolos con las entradas de otras tablas de flujos Counters Los contadores están mantenidos por tabla, por flujos, por puertos y por cola. Los contadores pueden estar implementados por software y mantenidos por contadores por hardware que tienen rangos más limitados. La tabla 3.2 contiene el conjunto de contadores requeridos [10]. Duration hace referencia a el tiempo que un flujo ha estado instalado en un switch. Los campos Receive Errors incluyen todos los errores específicos, incluyendo frame, overrun y errores de CRC además de algunos otros Mensajes del protocolo OpenFlow El protocolo consiste en 3 tipos de mensajes: controlador a switch, asíncrono y asimétrico. Controlador a switch se envían para: Especificar, modificar o borrar definiciones de flujos. Solicitar información acerca de las capacidades del switch. Obtener información como los contadores del switch. Enviar paquetes de vuelta al switch para su procesamiento después de que un nuevo flujo se ha creado. Mensajes asíncronos se envían al switch para: 17

28 3 OpenFlow Counter Bits Per Table Active Entries 32 Packet Lookups 64 Packet Matches 64 Per Flow Receives Packets 64 Received Bytes 64 Duration (seconds) 32 Duration (nanoseconds) 32 Per Port Received Packets 64 Transmitted Packets 64 Received Bytes 64 Transmitted Bytes 64 Receive Drops 64 Transmit Drops 64 Receive Errors 64 Transmit Errors 64 Receive Frame Alignmet Errors 64 Receive Overrun Errors 64 Receive CRC Errors 64 Collisions 64 Per Queue Transmit Packets 64 Transmit Bytes 64 Transmit Overrun Errors 64 Tabla 3.2: Lista requerida de contadores para usar en mensajes de estadísticas 18

29 3.2 Funcionamiento de OpenFlow Ingress Port Ether Src Ether Dst Ether type VLAN id VLAN Priority IP src IP dst IP proto IP Tos TCP/UDP src port TCP/UDP dst port Tabla 3.3: Campos de los paquetes usados para matching Enviar al controlador el paquete que no coincide con los flujos existentes. Informar al controlador que el flujo ha sido eliminado porque su parámetro TTL o el timer de inactividad han vencido. Informar al controlador de un cambio en el estado de un puerto o de un error que ha ocurrido en un switch. Ejemplos de estas circunstancias son cuando los links se caen o cuando un paquete llega con una instrucción de reenvío no especificada. Mensajes simétricos pueden ser enviados por el switch o el controlador y se usan para: Los mensajes de hello que se intercambian el controlador y el switch al comienzo. Mensajes de echo usados para determinar la latencia de la conexión controladorswitch y para verificar que esta conexión sigue operativa. Mensajes experimentales para proveer un camino para futuras extensiones de la tecnología OpenFlow Matching Cuando se recibe un paquete el Switch OpenFlow realiza las acciones que se ven en la figura 3.2 [10]. El switch comienza haciendo una búsqueda en la primera tabla de flujo. Las tablas de flujos se numeran empezando por el cero, y basado en esta primera búsqueda realizara búsquedas en otras tablas de flujo. A los campos de la tabla 3.3 que coinciden con alguna entrada se les extrae del paquete. Los campos que se utilizan para buscar coincidencias dependen del tipo del paquete y típicamente incluyen varios campos de cabecera, las coincidencias también se pueden hacer en base al puerto de entrada o por campos de metadatos. Los metadatos se usarán para poder mandar información entre las tablas en un switch. Un paquete coincide con una entrada de la tabla de flujos si los valores de los campos del paquete que se usan para la búsqueda están definidos en la misma. 19

30 3 OpenFlow Si tiene un valor ANY (omitido), coincidirá con todos los valores posibles en la cabecera. Si el switch trabaja con mascaras arbitrarias para campos específicos se podrá afinar mucho más las coincidencias. El paquete solo coincidirá también tiene la prioridad más alta Los contadores asociados a la tabla seleccionada deben ser actualizados y el set de instrucciones incluido en el flujo seleccionado, será aplicado. Si hay múltiples coincidencias y todas tienen configuradas la misma prioridad, la entrada de flujo seleccionada esta explícitamente indefinida. Está especificación no tiene en cuenta si el switch recibe un paquete corrupto o con un formato que no es el adecuado. Figura 3.2: Proceso de matching 3.3. Probando OpenFlow Explicación teórica. Veamos como se comportaría un switch OpenFlow (S1 ), en el supuesto de que el host H1 realizara una petición a un servidor HTTP alojado en el host H4 [11]. Ver 20

31 3.3 Probando OpenFlow Figura 3.3: Topología figura 3.3. H1 envía un paquete SYN para intentar iniciar la conexión. Cuando llega a S1 realiza el proceso de matching (figura 3.2), en esencia lo que hace es buscar si hay alguna entrada de flujo de la tabla de flujo cuyo campo match coincida con la cabecera del paquete SYN. En este caso, al ser el primer paquete que recibe S1, este todavía no tiene instalado ningún flujo por lo que opta por enviar un PACKET_IN al controlador, el cual contiene entre otros campos el buffer_id, que está generado de forma secuencial, además de el paquete SYN original. Figura 3.4. Ahora el controlador se encarga de procesar el PACKET_IN. En esta parte es cuando entra en escena la labor del programador que tiene que encargarse de decidir que hacer con el PACKET_IN. Por ejemplo se podrían uno de estos dos casos o los dos a la vez: 1. Simplemente decirle a S1 que envíe el paquete que recibió el controlador por el puerto 4 de S1. Para esto el controlador envía un PACKET_OUT (ver 21

32 3 OpenFlow Figura 3.4: PACKET_IN 22

33 3.3 Probando OpenFlow Figura 3.5: PACKET_OUT a figura 3.5) el cual contiene el paquete original, el mismo buffer_id que contenía el PACKET_IN y una acción que indica que el paquete se envíe por el puerto Enviarle a S1 un paquete FLOW_MOD (ver figura3.6) indicándole que instale un flujo (flow) el cual diga que todos los paquetes en cuya cabecera figure el puerto TCP 80 y que lleguen por el puerto eth1, que corresponde con H1 (estas dos opciones formarían el campo MATCH, en este caso lo formarían los campos Ingress Port y TCP dst Port. Tabla 3.3) sean enviados por por el puerto eth4, que corresponde con H4 (esto formaría el campo ACTION ). Además se añaden otros datos más indicados en la figura 3.6. Posteriormente el paquete SYN llegará a su destinatario. Una vez el paquete SYN ha llegado H4 envía de vuelta el paquete SYN/ACK. Una vez más el controlador tendrá que decidir que hacer con este paquete, ya que no encuentra ninguna referencia en su tabla de flujos. Así que podremos realizar las 23

34 3 OpenFlow Figura 3.6: FLOW_MOD a 24

35 3.3 Probando OpenFlow Figura 3.7: PACKET_OUT b dos mismas acciones descritas anteriormente pero en sentido inverso. Figuras 3.7 y 3.8. Finalmente los mensajes restantes, encontrarán una entrada de flujo de acuerdo a sus cabeceras, por lo que los paquetes serán redirigidos directamente sin necesidad de que S1 tenga que comunicarse con el controlador. Ver figura 3.9. En la figura 3.10 podemos observar como efectivamente primero llega un PAC- KET_IN al controlador y este se encarga de instalar un flujo mediante un mensaje FLOW_MOD. Esto ocurre en los dos sentidos por los que viaja el paquete. 25

36 3 OpenFlow Figura 3.8: FLOW_MOD b 26

37 3.3 Probando OpenFlow Figura 3.9: Ultimos paquetes 27

38 3 OpenFlow Figura 3.10: Wireshark Packet-in y Flow-mod 28

39 4 Software utilizado 4.1. Controladores Como hemos visto anteriormente un controlador básicamente añade y elimina entradas en la tabla de flujos. Existen numerosos controladores disponibles para OpenFlow pero nos centraremos solo en algunos de ellos. Se ha llegado a la conclusión de que finalmente se usará OpenDaylight, debido a la mayor cantidad de documentación, ejemplos e información disponible, que hará más sencilla la tarea de desarrollar un programa para el controlador OpenDaylight OpenDaylight [12] es un proyecto open-source. Se trata de un controlador implementado en software contenido dentro de su propia máquina virtual de Java (JVM). Como tal, puede ser desplegado en cualquier plataforma que soporte Java. El controlador contiene APIs abiertas que son utilizadas por las aplicaciones. OpenDaylight soporta el framework OSGi y REST bidireccional. El framework OSGi se utiliza para las aplicaciones que se ejecutan en el mismo espacio de direcciones que el controlador mientras que REST API se utiliza para aplicaciones que no se ejecutan en el mismo espacio de direcciones que el controlador. La lógica de negocio y los algoritmos residen en las aplicaciones. Estas aplicaciones utilizan el controlador para reunir la inteligencia de red, ejecutar algoritmos para realizar análisis y, seguidamente, usar el controlador para crear nuevas reglas a través de la red. El propio controlador contiene una colección de módulos enlazables dinámicamente para realizar tareas de red. Hay una serie de servicios de red base para tareas como ver que los dispositivos se encuentran dentro de la red y sus capacidades, la recopilación de estadísticas, etc. Además otros servicios y extensiones pueden ser añadidos al controlador para aumentar la funcionalidad SDN. La interfaz de bajo nivel es capaz de soportar múltiples protocolos (plugins separados) como OpenFlow 1.0, OpenFlow 1.3, BGP-LS, etc. Estos módulos están 29

40 4 Software utilizado Figura 4.1: OpenDaylight Helium dinámicamente conectados a la Service Abstraction Layer (SAL). La SAL contiene servicios de dispositivos para los módulos de niveles más altos. La SAL determina cómo cumplir con el servicio solicitado, independientemente del protocolo utilizado entre el controlador y los dispositivos de red. El controlador ofrece una serie de core bundles, cada uno de ellos exporta servicios importantes a través de Java Interfaces. En la tabla 4.1 se ofrece una lista de algunos bundles importantes que ofrece a la hora de desarrollar servicios de red. Cada una de estas interfaces ofrece una serie de métodos [13] que dan facilidad a para el desarrollo de los servicios de red en Java, más adelante se explicará algunos de estos métodos más importantes. Para más información [14, 15]. AD-SAL vs MD-SAL La SAL no es más que cruce que conecta el plugin del protocolo y los Módulos de Función de Red (Topology Manager, Statistics Manager, Switch Manager... ). Las API SAL son los contratos a los que los plugins de protocolo y los módulos de NFS 30

41 4.1 Controladores Bundle Interface exportadora Descripción arphandler IHostFinder Componente responsable del aprendizaje de las localizaciones del los hosts usando ARP. hosttracker IfIptoHost Localiza los hosts relativos a la red SDN. switchmanager ISwitchManager Componente que maneja el inventario de información de todos los nodos (switches) conocidos por el controlador. topologymanager ITopolgyManager Maneja el grafo de la red completa. statisticsmanager IStatisticsManager Componente a cargo de usar el ReadService del SAL que colecta todas las estadísticas de la red SDN sal IReadService Interface que provee la vista hardware de los flujos, colas, puertos de los nodos de red. sal ITopolgyService Métodos de topología proporcionados por SAL hacia las aplicaciones. sal IFlowProgrammerService Interface para instalar, modificar o eliminar flujos en los nodos de red. sal IDataPacketService Servicios de paquetes de datos de SAL provistos para las aplicaciones. Tabla 4.1: Bundles importantes de OpenDaylight 31

42 4 Software utilizado se adhieren con el fin de ser capaz de hablar el uno al otro. En la tabla 4.2 se comparan AD-SAL y MD-SAL [16]. Se ha optado por usar AD-SAL ya que se ha encontrado un mayor número de documentación y ejemplos varios, en contraposición con MD-SAL que siendo más reciente es más complicado encontrar ejemplos concretos Ryu Ryu es un componentes básico de las redes definidas por software. Provee de componentes software, las API que facilitan a los desarrolladores la tarea de crear aplicaciones de control y gestión de la red. Ryu soporta varios protocolos para la gestión de dispositivos de red, como OpenFlow, Netconf, OF-config, etc. En cuanto a OpenFlow, Ryu soporta totalmente las versiones 1.0, 1.2, 1.3, 1.4 y las Nicira Extensions. Además Ryu posee certificaciones para trabajar en dispositivos de distintas marcas. Todo el código esta disponible libremente a través de la licencia Apache 2.0. Ryu está totalmente escrito en Python. Ryu significa «flow» en japonés. Ryu posee gran cantidad de documentación, ordenada, y fácil de comenzar a utilizar. Para más información[17, 18] Floodlight El controlador SDN Floodlight es un controlador de clase empresarial, está disponible con licencia Apache para casi cualquier propósito. Es apoyado por una gran comunidad de desarrolladores que incluyen ingenieros de Big Switch Networks. Floodlight está diseñado para trabajar con un gran numero de switches, routers, switches virtuales y puntos de acceso compatibles con el protocolo OpenFlow. Es un sistema multiplataforma ya que funciona sobre la máquina virtual de Java. Para más información[19] NOX/POX NOX es una pieza del ecosistema de las Redes Definidas por Software (SDN). Específicamente es una plataforma para crear aplicaciones de control de red. De hecho mientras que ahora llamamos SDN a un número creciente de proyectos académicos, la primera tecnología en ser realmente conocida por SDN fue Openflow y NOX fue inicialmente desarrollada por Nicira Networks codo con codo con OpenFlow (NOX fue el primer controlador SDN). Nicira donó NOX a la comunidad de desarrolladores 32

43 4.1 Controladores AD-SAL API-Driven SAL The SAL APIs, request routing between consumers and providers, and data adaptations are all statically defined at compile/build time. The AD-SAL typically has both NB and SB APIs even for functions/services that are mapped 1:1 between SB Plugins and NB Plugins. In AD-SAL there is a dedicated REST API for each northbound/southbound plugin. he AD-SAL provides request routing (selects an SB plugin based on service type) and optionally provides service adaptation, if an NB (Service, abstract) API is different from its corresponding SB (protocol) API. Request routing is based on plugin type: the SAL knows which node instance is served by which plugin, and when an NB Plugin requests an operation on a given node, the request is routed to the appropriate plugin which then routes the request to the appropriate node. AD-SAL is stateless Limited to flow-capable device and service models only MD-SAL Model-Driven SAL The SAL APIs, request routing between consumers and providers are defined from models, and data adaptations are provided by internal adaptation plugins. The MD-SAL allows both the NB plugins and SB plugins to use the same API generated from a model. One plugin becomes an API (service) provider; the other becomes an API (service) Consumer. MD-SAL provides a common REST API to access data and functions defined in models. The MD-SAL provides request routing and the infrastructure to support service adaptation, but it does not provide service adaptation itself; service adaptation is provided by plugins. Request Routing in the MD-SAL is done on both protocol type and node instances, since node instance data is exported from the plugin into the SAL. MD-SAL can store data for models defined by plugins: provider and consumer plugins can exchange data through the MD-SAL storage Model agnostic. It can support any device and/or service models and is not limited to flow-capable device and service models only AD-SAL services usually provide both In MD-SAL, Service model APIs only provide asynchronous and synchronous versions of the asynchronous APIs, but they return a same API method. java.concurrent.future object, which allows a caller to block until the call is processed and a result object is available. Same API can be used for both synchronous and asynchronous approach. Thus MD-SAL encourages asynchronous approach to application design but does not preclude synchronous applications. Tabla 4.2: AD-SAL vs MD-SAL 33

44 4 Software utilizado Figura 4.2: Floodligh 34

45 4.2 Mininet en el año 2008, y desde entonces ha sido la base para muchos proyectos en el inicio de las SDN. NOX provee a un desarrollador de una API C++ para OpenFlow 1.0. POX es el hermano pequeño de NOX. En esencia, es una plataforma para el rápido desarrollo y prototipado para el control de la red por software utilizando Python. Es uno de un número creciente de frameworks para SDN (incluyendo NOX, Floodlight, Opendaylight...) con el fin de prestar ayuda para programar un controlador OpenFlow. POX además va más allá de eso. Para más información acerca de NOX y POX [20] Mininet Mininet [21] es un emulador de red que ejecuta una colección de dispositivos finales, switches, routers y enlaces en un solo core de Linux. Se utiliza la virtualización ligera para hacer que un solo sistema parezca una red completa. Los programas que se ejecutan pueden enviar paquetes a través de lo que parece ser una interfaz de Ethernet real, con una velocidad de enlace y con retardo. Los paquetes se procesan por lo que parece un verdadero interruptor de Ethernet, un enrutador o middlebox, con una determinada cantidad de colas. Cuando dos programas, como un iperf cliente y el servidor, se comunican a través mininet, el rendimiento medido debe coincidir con el de dos máquinas nativas más lentas. En resumen, los dispositivos virtuales de mininet, conmutadores, enlaces y los controladores se crean utilizando software en lugar de hardware, en su mayor parte el comportamiento es similar a los elementos de hardware Ventajas e inconvenientes de Mininet Mininet presenta una serie de ventajas e inconvenientes al simular una red, las cuales se presentan a continuación. Ventajas Rápido: la puesta en marcha de una red simple tarda sólo unos segundos. Esto significa que el bucle de gestión edit-debug puede ser muy rápido. Se pueden crear topologías personalizadas: un solo switch, grandes topologías tipo Internet... Puede correr programas reales: puede correr cualquier programa que se pueda ejecutar en Linux. 35

46 4 Software utilizado Compartir resultados: al ser un sistema cerrado es fácil compartir el código y ejecutarlo en distintas máquinas. Se pueden ejecutar experimentos simples escritos en Python, por ejemplo un servidor web simple usando un pequeño comando. Inconvenientes Todos los hosts mininet comparten el mismo sistema de archivos y el espacio PID. Actualmente mininet no hace NAT fuera de su sistema. Los host no pueden hablar directamente a Internet a menos que proporcione un medio para que lo hagan (se pueden configurar los hosts mininet para que tengan conectividad externa o para añadirles una interfaz física). Lo más importante que se tiene que tener en cuenta para los experimentos de red, es que probablemente habrá que utilizar enlaces más lentos, por ejemplo 10 o 100 Mb/s en lugar de 10 Gb/s, debido al hecho de que los paquetes son transmitidos por un conjunto de conmutadores de software, los recursos de la CPU que comparten la memoria, y por lo general tienen un menor rendimiento que el hardware de conmutación dedicado [6] vswitch Open vswitch es un sistema de switch virtual, diseñado específicamente para habilitar automatización y despliegue de interfaces de red de manera programada, además soporta su distribución alrededor de múltiples servidores físicos, lo que lo hace ideal para la construcción de esquemas de redes virtuales para nubes. OpenVSwitch es el esquema por defecto de gestión de redes de Mininet y se incluye preinstalado en la máquina virtual de Mininet Wireshark Wireshark [22, 23], antes conocido como Ethereal, es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones, para desarrollo de software y protocolos, y como una herramienta didáctica. Cuenta con todas las características estándar de un analizador de protocolos de forma únicamente hueca. La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver 36

47 4.4 Iperf todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. También incluye una versión basada en texto llamada tshark. Permite examinar datos de una red viva o de un archivo de captura salvado en disco. Se puede analizar la información capturada, a través de los detalles y sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo que queremos ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP Iperf Iperf [24, 25] es una herramienta que se utiliza para hacer pruebas en redes informáticas. El funcionamiento habitual es crear flujos de datos TCP y UDP y medir el rendimiento de la red. Iperf fue desarrollado por el Distributed Applications Support Team (DAST) en el National Laboratory for Applied Network Research (NLANR) y está escrito en C++. Iperf permite al usuario ajustar varios parámetros que pueden ser usados para hacer pruebas en una red, o para optimizar y ajustar la red. Iperf puede funcionar como cliente o como servidor y puede medir el rendimiento entre los dos extremos de la comunicación, unidireccional o bidireccionalmente. Es software de código abierto y puede ejecutarse en varias plataformas incluyendo Linux, Unix y Windows. UDP: Cuando se utiliza el protocolo UDP, Iperf permite al usuario especificar el tamaño de los datagramas y proporciona resultados del rendimiento y de los paquetes perdidos. TCP: Cuando se utiliza TCP, Iperf mide el rendimiento de la carga útil. Un detalle a tener en cuenta es que Iperf usa 1024*1024 para medidas en megabytes y 1000*1000 para megabits Eclipse Eclipse [26, 27] es un programa informático compuesto por un conjunto de herramientas de programación de código abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE 37

48 4 Software utilizado de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse). Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios. Se ha usado la versión Eclipse IDE for Java Developers 1 para MAC OS X de 64 bits ya que contiene la herramienta Maven preinstalada Maven Maven [28, 29] es una herramienta de software para la gestión y construcción de proyectos Java creada por Jason van Zyl, de Sonatype, en Es similar en funcionalidad a Apache Ant (y en menor medida a PEAR de PHP y CPAN de Perl), pero tiene un modelo de configuración de construcción más simple, basado en un formato XML. Estuvo integrado inicialmente dentro del proyecto Jakarta pero ahora ya es un proyecto de nivel superior de la Apache Software Foundation. Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado Uso del software Mininet Como hemos comentado anteriormente, Mininet [21] es un software que nos permite emular una red que usa el protocolo OpenFlow. La forma de puesta en marcha de Mininet más sencilla es usar la máquina virtual que se proporciona en su página web, esta contiene el Mininet propiamente dicho, todos los binarios OpenFlow y más herramientas preinstaladas (p.e. Wireshark) y modificaciones de la configuración del kernel que dan soporte a redes Mininet más complejas. Se puede descargar la versión 1 Descarga Eclipse IDE for Java Developers 38

49 4.6 Uso del software Figura 4.3: Mininet VM ifconfig más reciente desde el siguiente enlace 2. En nuestro caso usaremos la versión «Mininet on Ubuntu bits». Para la ejecución de la máquina virtual se usara el software de virtualización VMware. En mi caso he configurado la VM una interfaz de red en modo bridge para poder tener acceso desde cualquier punto de mi red. Ya que la VM no incluye interfaz gráfica la forma más cómoda de manejar Mininet es a través de SSH. En nuestro caso accederemos desde OS X así que no habrá que instalar nada adicional ya que viene con un cliente ssh instalado, desde Windows podemos usar cualquier cliente SSH disponible (p.e. Putty). Antes de todo habrá que mirar con el comando ifconfig la dirección IP de la VM Mininet, el nombre de usuario y la contraseña son mininet (Figura 4.3). Para acceder a la máquina virtual abrimos una terminal y usamos el siguiente comando e introducimos la contraseña «mininet»: 2 Descargar Mininet VM https://github.com/mininet/mininet/wiki/mininet-vm-images 39

50 4 Software utilizado $ ssh -Y La opción -Y permite ejecutar interfaz gráfica usando el servidor X11 de la máquina remota que nos servirá para poder abrir ventanas adicionales o para poder usar Wireshark y MiniEdit. Para poder usarlo necesitamos tener instalado el software XQuartz 3 para OS X o bien Xming 4 para Windows, en Linux X11 viene por defecto. CLI Una vez dentro de la máquina remota usaremos el siguiente comando para iniciar Mininet (Figura 4.4). $ sudo mn Con ello ya estaremos ejecutando mininet. Mininet por defecto carga una topología simple con un controlador c0 conectado a un switch s1 y a este dos hosts, h1 y h2 (ver Figura 4.5). Es posible añadir más opciones al comando que nos permitirán personalizar nuestra red. Por ejemplo el siguiente comando cargaría una red en árbol de dos niveles de switches Open vswitch, además indicamos que se conecte a un controlador remoto y su dirección ip. $ sudo mn --switch=ovsk --topo=tree,2 --controller=remote,ip= Ahora dentro del CLI podemos realizar varias acciones. Por ejemplo podemos comprobar la conectividad de la red con el comando pingall que mandará un ping desde todos los host de la red a todos los host restantes, o bien podemos usar el comando dump para visualizar los dispositivos que esta nuestra red. Además poniendo el nombre del dispositivo seguido de un espacio y un comando de unix, podremos ejecutar comandos en los dispositivos directamente desde la consola de Mininet (ej. h1 ping h2). Para salir usaremos el comando exit. Para más información [30]). 3 Descargar XQuartz 4 Descargar Xming 40

51 4.6 Uso del software Figura 4.4: mininet> 41

52 4 Software utilizado Figura 4.5: Topología simple Mininet Topologías Mininet permite ejecutar algunas topologías predefinidas usando algunos parámetros en el CLI. Por ejemplo el siguiente comando nos permitirá cargar una topología en árbol de dos niveles: $ sudo mn --topo=tree,2 Más interesante aun es la posibilidad de crear topologías personalizadas. La forma más sencilla es usar MiniEdit, que es un programa escrito en python que nos permite hacer eso mismo de forma gráfica. Este mismo ha sido usado para crear las topologías que usaremos más adelante. Para ejecutarlo basta con lanzarlo como cualquier script python, en concreto en nuestra máquina virtual de Mininet se haría con el siguiente comando: $ sudo ~/mininet/examples/miniedit.py 42

53 4.6 Uso del software Nos abrirá una ventana como esta (Figura 4.6) que nos permitirá añadir los switches OpenFlow, los hosts, el controlador así como sus enlaces. También podremos modificar todas sus características. Algo importante que debemos hacer es decirle que el controlador es remoto, para ello, simplemente haremos click derecho en el icono del controlador, pinchamos en Properties y en Controller Type elegimos Remote Controller. Además debemos cambiar la dirección IP por la del host donde se iniciará OpenDaylight (Figura 4.7). También indicarle a MiniEdit que cuando lancemos el script python de Mininet nos cargue el CLI para que podamos trabajar desde su consola, para hacer esto debemos ir a Edit, Preferences y seguidamente marcar la casilla Start CLI (Figura 4.8). Para más información acerca de como usar MiniEdit [31]. Una vez tengamos nuestra topología creada la guardaremos y la exportaremos a Level 2 Script que nos creará un script python de mininet, el cual simplemente lanzaremos y tendremos nuestro mininet listo. Para ello primero habrá dar permisos de ejecución al archivo que exportamos y seguidamente podremos ejecutar el script: $ sudo chmod +x nombre_script.py $ sudo./nombre_script.py Wireshark Para este trabajo, usaremos el software Wireshark [23] que nos permitirá visualizar los paquetes de nuestra red. Wireshark está incluido en la máquina virtual de mininet. Este incluye un plugin para OpenFlow que permite visualizar los paquetes de forma mucho más ordenada, además también permite el filtrado de estos. Para filtrar los paquetes OpenFlow usaremos el código «of». Más adelante veremos como se inicia la conexión en el protocolo OpenFlow visualizando los paquetes mediante este plugin. Iniciar Wireshark Para ejecutar Wireshark (Figura 4.9) basta con lanzarlo usando el siguiente comando en la máquina de Mininet: $ sudo wireshark& 43

54 4 Software utilizado Figura 4.6: Topología con MiniEdit 44

55 4.6 Uso del software Figura 4.7: Controlador remoto MiniEdit Figura 4.8: Activar CLI MiniEdit 45

56 4 Software utilizado Figura 4.9: Ventana de Wireshark 46

57 OpenDaylight 4.6 Uso del software Como hemos dicho anteriormente, OpenDaylight [12] es un controlador OpenFlow escrito en Java. En nuestro caso hemos usado la versión base que es la más sencilla de usar, ya que desde el principio está todo montado y no es necesario instalar más cosas. En concreto usaremos una versión modificada de SDN Hub [32], ya que es más liviana que la versión original ya que solo incluye los módulos necesarios para la ejecución de nuestro programa. Esta versión se incluye en los archivos externos entregados junto a la documentación. Para lanzar el controlador nos iremos a la carpeta de OpenDaylight y ejecutaremos el comando (Figura 4.10): $./run.sh Es posible que previamente haya que dar permisos de ejecución, si esto ocurre, usaremos el siguiente comando para solucionar esto: $ sudo chmod +x run.sh Más adelante veremos más a fondo como usar el controlador OpenDaylight comunicándolo con la máquina de Mininet para nuestro caso concreto. 47

58 4 Software utilizado Figura 4.10: Controlador OpenDaylight iniciándose 48

59 5 Caso práctico: Mejora de la eficiencia energética en una red SDN 5.1. Explicación teórica Se ha desarrollado un módulo para OpendayLight llamado flowapp que intenta mejorar la eficiencia energética de redes de switches utilizando para ello tecnología SDN. En concreto usaremos Opendaylight y Mininet (que incluye switches Open- Flow). Se usarán tres topologías distintas para comprobar el grado de mejora en cada una de ellas. Estas son, topología en malla (figura 5.1), topología en anillo (figura 5.2) y topología en árbol (figura 5.3). A continuación pasaremos a explicar los códigos fuentes del módulo OpenDaylight programado en Java y de las topologías de Mininet escritas en Python. El gasto energético de una interfaz de red es proporcional al throughtput de esa interfaz. Al aumentar el throughtput también aumentará el gasto energético de la forma que se indica en la tabla, de forma que prácticamente una interfaz de red con un throughput de 1000Mpbs (que diremos que está en nivel 2) tiene solamente el doble del gasto energético de una interfaz con un throughtput de 100Mbps (diremos que está en nivel 1), de modo que lo que se pretende es que la mayoría de las conexiones estén en nivel 2 lo que hará que haya mayor numero de interfaces en StandBy (que son las que menos gasto energético tienen). El módulo se encarga de calcular las rutas energéticamente óptimas entre dos hosts y de instalarlas en la red, permitiendo la comunicación en cualquier topología de red SDN. El módulo flowapp permite la configuración de distintos parámetros. Entre ellos se encuentran tres importantes que nos permitirán cambiar los costes (usados por el algoritmo shortest path de Dijkstra) dados a cada nivel energético (StandBy, Nivel1 o Nivel2). Así el módulo se encargará de calcular las rutas más óptimas energéticamente hablando. Variando estos valores conseguiremos modificar el comportamiento del ahorro energético, consiguiendo más ahorro energético (se usarían menos enlaces) repercutiendo en el aumento del throughtput total de la red, para conseguir 49

60 5 Caso práctico: Mejora de la eficiencia energética en una red SDN Figura 5.1: Topología en malla esto deberíamos asignarle un valor alto a las interfaces en StandBy, un valor medio a las interfaces Nivel1 y un valor bajo a las interfaces Nivel2, así intentaríamos usar lo menos posible las interfaces en StandBy. Si asignáramos el mismo coste a todos los niveles permitiríamos que la red se comporte de forma normal sin conseguir eficiencia energética y, simplemente, consiguiendo forwarding entre host usando el controlador Desarrollo del código: Java Algoritmo de Dijkstra El algoritmo de Dijkstra (ver algorítmo 5.1), también llamado algoritmo de caminos mínimos, es un algoritmo para la determinación del camino más corto dado un vértice origen al resto de los vértices en un grafo con pesos en cada arista. Su nombre se refiere a Edsger Dijkstra, quien lo describió por primera vez en La idea subyacente en este algoritmo consiste en ir explorando todos los caminos más cortos que parten del vértice origen y que llevan a todos los demás vértices; cuando se obtiene el camino más corto desde el vértice origen, al resto de vértices 50

61 5.1 Explicación teórica Figura 5.2: Topología en anillo 51

62 5 Caso práctico: Mejora de la eficiencia energética en una red SDN Figura 5.3: Topología en árbol 52

63 5.1 Explicación teórica Algoritmo 5.1 Algoritmo de Dijkstra Require: Directed network G = (V, E, w), with non-negative edge weights and source s V. Ensure: Array µ( ) of length n, where µ(u) is the maximum reliability for each u V, and array pred( ) of length n, where pred(u) is the parent of vertex u in the shortest path tree rooted at s. S = ; S = V for every u V do µ(p ) = 0; end for µ(s) = 1; pred(s) = 0; while S < n do let u S be the vertex for which µ(u) = min u S {d(u)}; S = S {u}; S = S {u}; for (u, w) E do if µ(w) < µ(u) wt(u, w) then µ(w) = µ(u) wt(u, w) end if end for end while que componen el grafo, el algoritmo se detiene. El algoritmo es una especialización de la búsqueda de costo uniforme, y como tal, no funciona en grafos con aristas de coste negativo (al elegir siempre el nodo con distancia menor, pueden quedar excluidos de la búsqueda nodos que en próximas iteraciones bajarían el costo general del camino al pasar por una arista con costo negativo) [33]. Consideraciones previas. Durante la explicación del código hay que tener en cuenta que: Los enlaces es llaman edges indistintamente, ya que es el nombre que toma este objeto en OpenDaylight. De la misma forma, un nodo (node) es lo mismo que un switch. Un nodeconnector a su vez es un puerto de un switch. 53

64 5 Caso práctico: Mejora de la eficiencia energética en una red SDN API AD-SAL Se ha usado el java-doc de AD-SAL OpenDaylight [13] para tener una referencia de los distintos métodos que se pueden usar a través de las Interfaces descritas en la tabla 4.1. Las dos interfaces más importantes para la realización de este proyecto han sido el Topology Manager y el Statistics Manager. Topology Manager: Nos da información acerca de la topología de la red. Su método más importante es getedges el cual nos devuelve un Map con todos los edges de la red. A partir del objeto edge podemos sacar el nodeconnector de cada extremo y de este último el node. Hay que tener en cuenta que el topologymanager entrega dos edges para cada enlace, uno en cada sentido. Por eso a la hora de crear el grafo de la red usaremos un grafo dirigido para que a la hora de calcular los caminos nos entreguen los edges en la dirección correcta. Statistics Manager: Entrega información de los contadores del protocolo Open- Flow de los switchs. Nos interesa para conocer los campos Transmitted Bytes y Received Bytes de los puertos (ver apartado3.2.4) con el fin de calcular su throughput. Código A continuación pasaremos a explicar las partes más relevantes del programa [14, 34]. Para más información consultar el código fuente el cual está totalmente comentado. PacketHandler.receiveDataPacket. Esta función es llamada cuando el controlador recibe un PACKET_IN desde cualquiera de los switches, como vemos en la figura 5.2 se comprueba que sea de tipo Ethernet para a continuación extraer las direcciones MAC origen y destino que contiene el paquete. Seguidamente se comprueba que se trate de un paquete IPv4 e igual que en el paso anterior, extraemos las direcciones IP origen y destino. Finalmente llamamos al método installpathflows que se encargará de calcular las rutas e instalarlas en los nodos correspondientes. PacketHandler.installPathFlows. El trabajo de esta función es la de calcular las rutas e instalarlas en toda la red (figuras 5.3 y 5.4). Primero se busca el nodo al que está conectado un host con la dirección dstaddr. Una vez encontrado, inicializamos el objeto path de tipo Path, una clase la cual contiene los métodos de cálculo de caminos usando el algoritmo Shortest Path de Dijkstra 54

65 5.1 Explicación teórica Función 5.2 receivedatapacket 55

66 5 Caso práctico: Mejora de la eficiencia energética en una red SDN basándonos en Framework para grafos JUNG 1. Para hacer esto nos basamos en la interfaz topologymanager con el fin de sacar una lista de edges los cuales usaríamos para crear un grafo. Además tenemos un Map llamado edgecost el cual contiene los costes actuales asociados a cada enlace (edge o arista). Una vez hecho esto, primeramente miraríamos si existe conexión entre los dos nodos y seguidamente calcularíamos el camino mediante el método getpath. El camino lo formarían una lista de edges los cuales instalaríamos para instalar un flujo en el nodo situado en el primer extremo del enlace (tail). En este flujo indicaríamos que todos los paquetes con dirección IP fuente srcaddr y dirección IP destino dstaddr se mandaran por la interfaz correspondiente al edge usado. Este paso lo realizaríamos tantas veces como edges tenga la lista edgepath. PacketHandler.programFlow. Dicha función (5.5) se encarga de crear los flujos e instalarlos en los nodos correspondientes. Primero se crea un objeto Match el cual contendrá los datos con los cuales se decidirá si un paquete hará uso del flujo o no según los datos de su cabecera. En nuestro caso simplemente seleccionaríamos los paquetes IPv4 con dirección IP fuente srcaddr y dirección IP destino dstaddr. El siguiente paso es crear la lista de acciones que realizarán los paquetes coincidentes con el match, le vamos a indicar solo una, que el paquete se envie por el puerto outconnector. Por último creamos el flujo usando los objetos match y actions, le asignamos los time_outs correspondientes y finalmente programamos el flujo en el nodo. PacketHandler.iniEdgeBps. Dicha función (5.6) asigna el nivel que tendrá cada enlace dependiendo de su throughput actual. Además devuelve la carga total de la red. Paths.buildGraph. Esta función (5.7) genera el grafo del cual calcularemos los caminos. Simplemente hay que añadir todas las aristas y sus dos vértices e indicar el tipo de arista (en nuestro caso será dirijida, ya que como hemos comentado antes topologymanager entrega un edge por cada sentido de un enlace). 1 Java Universal Network/Graph Framework 56

67 5.1 Explicación teórica Función 5.3 PacketHandler.installPathFlows Parte 1 57

68 5 Caso práctico: Mejora de la eficiencia energética en una red SDN Función 5.4 PacketHandler.installPathFlows Parte 2 58

69 5.1 Explicación teórica Función 5.5 PacketHandler.programFlow 59

70 5 Caso práctico: Mejora de la eficiencia energética en una red SDN Función 5.6 PackeHandler.iniEdgeBps Función 5.7 Paths.buildGraph 60

71 5.1 Explicación teórica Figura 5.4: dependencies Desarrollo del código: Maven Como hemos dicho anteriormente Maven automatiza el proceso de añadir las dependencias necesarias para nuestro proyecto a la hora de compilar. Para hacer esto usa el fichero pom.xml (se encuentra dentro del proyecto de flowapp) el cual contiene el nombre de las dependencias necesarias y repositorios donde conseguirlas. Para añadir más dependencias simplemente hay que buscar el nombre de la dependencia deseada 2 y añadirla en el apartado depdendencies (figura 5.4) dentro del fichero pom.xml [35]. Una vez tenemos nuestro fichero pom.xml configurado para compilar nuestro proyecto lo haremos pinchando con el botón derecho en nuestro proyecto de eclipse, nos vamos a Run as y finalmente pinchamos en Maven install como se muestra en la 2 Dependencias Opendaylight https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/ 61

72 5 Caso práctico: Mejora de la eficiencia energética en una red SDN figura Desarrollo del código: Python Los scripts python programados simplemente se encargan de generar tráfico para comprobar el rendimiento de la red. Se encargan de lanzar comandos en cada host de forma automática. Concrétamente se lanzan comandos ping e iperf cada 10 segundos. Inicialmente solo se usaron comandos iperf para generar tráfico UDP ya que esta herramienta solo permitía modular el ancho de banda de este tipo de tráfico. El problema vino con que el controlador OpenDaylight no procesaba los paquetes UDP con la rapidez necesaría, y mientras se estaban instalando las rutas a lo largo de la red, seguian llegando paquetes al controlador ya que no se encontraban flujos asociados por que no había dado tiempo a instalarlos. Para poder solucionarlo es optó por mandar primero un paquete ICMP mediante la aplicación ping para que al controlador le diera tiempo de calcular las rutas e instalarlas. Una vez hecho esto se haría el iperf UDP y ya se encontrarían los flujos instalados por lo que no llegarían nunca al controlador. Como vemos en la figura 5.6 primero ejecutamos iperf en modo servidor en todos los hosts y seguidamente comienzan a mandarse en bucle los ping y las peticiones iperf (con ancho de banda de 50Mbps y durante 50 segundos) Funcionamiento Configuración módulo flowapp Para cambiar la configuración del módulo solamente debemos cambiar los valores del fichero flowapp.conf. Estos valores son los siguientes: valor» Tiempo en segundos para el idle_time_out de los flujos que se instalarán. Por defecto 15. valor» Tiempo en segundos para el hard_time_out de los flujos que se instalarán. Por defecto 7200 (dos horas) valor» Tiempo en segundos para el refresco del calculo de niveles. Por defecto 10. valor» Troughtput en bytes por segundo mediante el cual se asignarán los niveles. Así pues los enlaces con un throughtput de 0 estarán en StandBy, los enlaces de 0 al valor estarán en Nivel1 y los enlaces cuyo 62

73 5.2 Funcionamiento Figura 5.5: Compilar con Maven 63

74 5 Caso práctico: Mejora de la eficiencia energética en una red SDN Figura 5.6: Código python iperfudp 64

75 5.2 Funcionamiento throughtput sea mayor al valor estarán en Nivel2. Por defecto (12.5MB/s = 100Mbps). valor» Energía en mw que consume una interfaz en StandBy. Por defecto 49. valor» Energía en mw que consume una interfaz en Nivel1. Por defecto 315. valor» Energía en mw que consume una interfaz en Nivel2. Por defecto 619. valor» Coste asignado a un enlace en StandBy. Por defecto 50. valor» Coste asignado a un enlace en Nivel1. Por defecto 15. valor» Coste asignado a un enlace en Nivel2. Por defecto 1. ruta» Ruta en la cual se guardarán los ficheros de monitorización. Por defecto «./» true/false» True si queremos mostrar los datos de monitorización en consola, false si no. Por defecto a true. También podemos añadir comentarios de la forma #+comentario. Si repetimos más de un comando, será siempre el último el que tendrá valor. Ejemplo de un fichero flowapp.conf creado: #Fichero de true 65

76 5 Caso práctico: Mejora de la eficiencia energética en una red SDN Iniciando OpenDaylight Partiendo de la base en que ya tenemos nuestro módulo compilado listo para usarse en la carpeta plugins dentro de opendaylight y configurado, la máquina virtual iniciada y los scripts de Python (para este paso se puede usar algún cliente SFTP como winscp 3 en Windows, Fugu 4 para Mac o Filezilla para Linux 5 bien usar el comando scp 6 desde la terminal.) en ella. Iniciamos OpenDaylight como dijimos en el apartado Abrimos una terminal, nos vamos a la carpeta opendaylight y ejecutamos el siguiente comando: $./run.sh Si está todo va bien en unos segundos nos debería aparecer la configuración cargada y comenzar a monitorizar a los 10 segundos, siempre que tengamos activado el modo monitor (ver figura 5.7) Iniciando Mininet Una vez tenemos OpenDaylight corriendo toca iniciar Mininet, para ello primero debemos conectarnos por ssh como muestra el apartado Ahora tenemos que iniciar nuestra topología, en nuestro caso usaremos las tres topologías descritas en el apartado 5.1. Cada topología se inicia con un fichero.py diferente. Por ejemplo probaremos el script malla6.py el cual contiene una topología en malla, la forma de lanzarlo es como se haría con cualquier ejecutable de unix, una cosa que hay que tener en cuenta es que mininet debe tener permisos de administrador, por lo tanto el comando quedaría así: $ sudo./malla6.py Esperaremos unos instantes y deberíamos tener acceso al CLI si el script de Mininet está bien configurado. Además en la consola de OpenDaylight veríamos que los switchs han sido reconocidos por el controlador y el monitor de comienza a mostrar información del nivel de las interfaces. Esperaremos unos segundos hasta que en el número total de interfaces aparezcan todas (tiene que se el doble del número de enlaces entre nodos). Para la topología en malla utilizada deberían ser Descargar winscp 4 Descargar Fugu 5 Descargar Filezilla https://filezilla-project.org/download.php?show_all=1 6 Cómo usar el comando scp 66

77 5.2 Funcionamiento Figura 5.7: OpenDaylight configuración y monitor 67

Microtutorial. Software Defined Networking

Microtutorial. Software Defined Networking Microtutorial Software Defined Networking ii Software Defined Networking (SDN) Abstract El SDN (Software Defined Networking) es una técnica emergente que concentra las funciones de control de la red en

Más detalles

Laboratorio de Redes de Computadores

Laboratorio de Redes de Computadores 3. Análisis de tráfico en una LAN 3.1 Introducción En esta práctica se va a trabajar sobre la misma configuración de red utilizada en la práctica anterior (Figura 32) y se van a hacer ejercicios muy similares,

Más detalles

Práctica 3 Observando la red

Práctica 3 Observando la red Práctica 3 Observando la red 1. Objetivos El objetivo principal que se persigue en esta práctica es ser capaz de observar el tráfico de red mediante un analizador de protocolos como Wireshark y comprender

Más detalles

IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW SWITCHES CARLOS ALBERTO CONTRERAS PARDO

IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW SWITCHES CARLOS ALBERTO CONTRERAS PARDO IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW SWITCHES CARLOS ALBERTO CONTRERAS PARDO PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGNIERÍA ELECTRÓNICA

Más detalles

REDES DE COMPUTADORES Laboratorio

REDES DE COMPUTADORES Laboratorio 1nsloo.cl REDES DE COMPUTADORES Laboratorio Práctica 1: Emulación de redes con NetGUI. 1. OBJETIVOS. El objetivo de esta práctica es aprender a utilizar la herramienta de emulación de redes Netkit / NetGUI,

Más detalles

ANEXO 2. Manual de instalación y configuración del entorno Mininet. Sergio Rodríguez Santamaría

ANEXO 2. Manual de instalación y configuración del entorno Mininet. Sergio Rodríguez Santamaría ANEXO 2 Manual de instalación y configuración del entorno Mininet Sergio Rodríguez Santamaría ÍNDICE 1. Introducción........ 3 2. Instalación del software de virtualización........ 4 3. Instalación Máquina

Más detalles

Práctica2 Observando la red

Práctica2 Observando la red Práctica2 Observando la red 1- Objetivos El objetivo principal que se persigue en esta práctica es ser capaz de observar el tráfico de red mediante un analizador de protocolos como Wireshark y comprender

Más detalles

SOFTWARE DEFINED NETWORKS

SOFTWARE DEFINED NETWORKS SOFTWARE DEFINED NETWORKS Ana Milena Rojas Calero (1), Álvaro Pachón (2). amrojas@admon.uniajc.edu.co, alvaro@icesi.edu.co. (1) Dirección de Tecnología. Institución Universitaria Antonio José Camacho (2)

Más detalles

REDES DE COMPUTADORES REDES Y SISTEMAS DISTRIBUIDOS

REDES DE COMPUTADORES REDES Y SISTEMAS DISTRIBUIDOS REDES DE COMPUTADORES REDES Y SISTEMAS DISTRIBUIDOS Título de la práctica Sesión Monitorización de redes con Ethereal Semana 15/01/2007 Laboratorio 2.2 Material utilizado PCs, PC-Router, Routers Linksys

Más detalles

Fig.1 Redes conectadas a Internet a través de routers IP

Fig.1 Redes conectadas a Internet a través de routers IP PRACTICA 4 EL PROTOCOLO IP Hasta ahora hemos visto aspectos relacionados con el hardware de red de nuestras máquinas: Acceso al adaptador de red y un mecanismo para la resolución de direcciones hardware.

Más detalles

UNIVERSIDAD DE CANTABRIA DEPARTAMENTO DE INGENIERÍA DE COMUNICACIONES GRUPO DE INGENIERÍA TELEMÁTICA

UNIVERSIDAD DE CANTABRIA DEPARTAMENTO DE INGENIERÍA DE COMUNICACIONES GRUPO DE INGENIERÍA TELEMÁTICA UNIVERSIDAD DE CANTABRIA DEPARTAMENTO DE INGENIERÍA DE COMUNICACIONES GRUPO DE INGENIERÍA TELEMÁTICA PROTOCOLOS PARA LA INTERCONEXIÓN DE REDES PRÁCTICA 1 CONFIGURACIÓN Y ANÁLISIS DE REDES TCP/IP Práctica

Más detalles

La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador.

La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador. La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador. Los derechos de autor han sido entregados a la ESCUELA POLITÉCNICA NACIONAL bajo el libre consentimiento del

Más detalles

Enrutamiento Estático

Enrutamiento Estático 192.168.2.30 192.168.1.10 Enrutamiento Estático 1 Descripción del experimento Se describirá la configuración de un sencillo experimento de enrutamiento estático utilizando el OCF. Este experimento demuestra

Más detalles

Nombre: Francis Ariel Jiménez Zapata. Matricula: 2010-0077. Tema: Trabajando con Windows Server 2008 Módulo 6. Materia: Sistema Operativo II

Nombre: Francis Ariel Jiménez Zapata. Matricula: 2010-0077. Tema: Trabajando con Windows Server 2008 Módulo 6. Materia: Sistema Operativo II Nombre: Francis Ariel Jiménez Zapata Matricula: 2010-0077 Tema: Trabajando con Windows Server 2008 Módulo 6 Materia: Sistema Operativo II Facilitador: José Doñe Introducción En este trabajo estaremos tratando

Más detalles

Conmutación Ethernet

Conmutación Ethernet Conmutación Ethernet Area de Ingeniería Telemática http://www.tlm.unavarra.es Redes de Banda Ancha 5º Ingeniería de Telecomunicación Puentes y conmutadores Conmutador Ethernet (switch, switching-hub) es

Más detalles

Examen 21 de febrero de 2011 (ref: eirc1103.odt)

Examen 21 de febrero de 2011 (ref: eirc1103.odt) Introducción a las Redes de Computador{aes y Comunicación de Datos Examen 21 de febrero de 2011 (ref: eirc1103.odt) Instrucciones Indique su nombre completo y número de cédula en cada hoja. Numere todas

Más detalles

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN UNICIENCIA 24 pp. 83-89 2010 IMPLEMENTACIÓN DE UN SERVIDOR FTP UTILIZANDO EL MODELO CLIENTE/SERVIDOR MEDIANTE EL USO DE SOCKETS EN LENGUAJE C UNIX CON EL FIN DE MEJORAR LOS TIEMPOS DE RESPUESTA EN LA RED

Más detalles

Multi Traffic Routing Grapher (MRTG)

Multi Traffic Routing Grapher (MRTG) UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGÍA COORDINACIÓN DE POST-GRADO Maestría en Ciencias de la Computación- Mención Redes de Computadoras Multi Traffic Routing Grapher

Más detalles

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio]

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] MÓDULO: SERVICIOS E RED Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] PARTE 1: Responde las siguientes preguntas tipo TEST. Solo hay una respuesta correcta. Dos respuestas incorrectas anulan una

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

Práctica 4: Ethernet, Switching y VLANs

Práctica 4: Ethernet, Switching y VLANs 75.43 Introducción a los Sistemas Distribuidos Práctica 4: Ethernet, Switching y VLANs Resumen En las redes locales, el concepto de VLAN permite separar virtualmente distintos segmentos de una misma red

Más detalles

Monitorización de red

Monitorización de red Gestión y Planificación de Redes y Servicios Monitorización de red Area de Ingeniería Telemática http://www.tlm.unavarra.es Grado en Ingeniería en Tecnologías de Telecomunicación, 4º Medir qué? Un Ejemplo

Más detalles

UNIVERSIDAD DE ALCALÁ - DEPARTAMENTO DE AUTOMÁTICA Área de Ingeniería Telemática LABORATORIO DE COMUNICACIÓN DE DATOS (CURSO 2011/2012)

UNIVERSIDAD DE ALCALÁ - DEPARTAMENTO DE AUTOMÁTICA Área de Ingeniería Telemática LABORATORIO DE COMUNICACIÓN DE DATOS (CURSO 2011/2012) UNIVERSIDAD DE ALCALÁ - DEPARTAMENTO DE AUTOMÁTICA Área de Ingeniería Telemática it LABORATORIO DE COMUNICACIÓN DE DATOS (CURSO 2011/2012) PRÁCTICA 5 EMULACIÓN DE REDES. CONFIGURACIÓN DE ROUTERS Objetivos

Más detalles

Capítulo 3. Software para el Monitoreo de Redes

Capítulo 3. Software para el Monitoreo de Redes Capítulo 3 Software para el Monitoreo de Redes No basta saber, se debe también aplicar. No es suficiente querer, se debe también hacer. Johann Wolfgang Goethe Software para el Monitoreo de Redes El estilo

Más detalles

Materia: Telefonía UNEFA 2013 Semestre 11. Prof. Ing. Eduardo Gutierrez. 1

Materia: Telefonía UNEFA 2013 Semestre 11. Prof. Ing. Eduardo Gutierrez. 1 Spanning tree (Spanning Tree Protocol) (SmmTPr o STP) es un protocolo de red de nivel 2 de la capa OSI (nivel de enlace de datos). Está basado en un algoritmo diseñado por Radia Perlman mientras trabajaba

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

Práctica 8: El analizador de protocolos Ethereal

Práctica 8: El analizador de protocolos Ethereal Práctica 8: El analizador de protocolos Ethereal Los analizadores de protocolos o de red, también conocidos vulgarmente como sniffers son herramientas de gran ayuda para los administradores de las redes

Más detalles

Capítulo 11: Capa 3 - Protocolos

Capítulo 11: Capa 3 - Protocolos Capítulo 11: Capa 3 - Protocolos Descripción general 11.1 Dispositivos de Capa 3 11.1.1 Routers 11.1.2 Direcciones de Capa 3 11.1.3 Números de red únicos 11.1.4 Interfaz/puerto del router 11.2 Comunicaciones

Más detalles

Introducción a redes Ing. Aníbal Coto Cortés

Introducción a redes Ing. Aníbal Coto Cortés Capítulo 5: Ethernet Introducción a redes Ing. Aníbal Coto Cortés 1 Objetivos En este capítulo, aprenderá a: Describir el funcionamiento de las subcapas de Ethernet. Identificar los campos principales

Más detalles

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010 Windows Azure Solutions with Microsoft Visual Studio 2010 www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso es una introducción

Más detalles

SEGURIDAD EN SISTEMAS INFORMÁTICOS

SEGURIDAD EN SISTEMAS INFORMÁTICOS Universidad Pública de Navarra Grupo de Redes, Sistemas y Servicios Telemáticos SEGURIDAD EN SISTEMAS INFORMÁTICOS Práctica 3 Seguridad perimetral: Filtrado de paquetes (Primera Parte) Introducción En

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA)

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) SOLUCIÓN (más completa que el mínimo requerido para obtener los máximos puntajes) Pregunta 1 En el sistema de nombre de dominio (DNS): a)

Más detalles

Cloudbuilder Next. Ventajas y características. Descubre todas sus funcionalidades. Índice

Cloudbuilder Next. Ventajas y características. Descubre todas sus funcionalidades. Índice Cloudbuilder Next Ventajas y características Descubre todas sus funcionalidades Índice 1. La solución más sólida del mercado 2. Qué es Cloudbuilder Next? 3. Qué ventajas aporta Cloudbuilder Next? 4. Qué

Más detalles

Práctica 7: Otras tecnologías en Ethernet

Práctica 7: Otras tecnologías en Ethernet Práctica 7: Otras tecnologías en Ethernet 1- Objetivos Con esta práctica completamos los temas alrededor de la configuración de equipos con interfaces Ethernet. Para ello veremos cómo emplear 802.1Q desde

Más detalles

Prácticas de laboratorio de Telemática II

Prácticas de laboratorio de Telemática II Prácticas de laboratorio de Telemática II Práctica 5 Departamento de Ingeniería Telemática (ENTEL) Mónica Aguilar Juanjo Alins Oscar Esparza Jose L. Muñoz Marcos Postigo Antoni X. Valverde II La composición

Más detalles

Laboratorio de Redes y Sistemas Operativos Trabajo Práctico Final

Laboratorio de Redes y Sistemas Operativos Trabajo Práctico Final Laboratorio de Redes y Sistemas Operativos Trabajo Práctico Final Tema: Instalación de X2GO Profesor: Di Biase José Luis Integrantes: Cardozo Griselda Chiniewicz Stefania Arnez Inochea Eric 1 Índice: 1.

Más detalles

WireShark. Este instructivo describe el uso del programa WireShark (antes llamado Ethereal) para examinar paquetes en una red de datos.

WireShark. Este instructivo describe el uso del programa WireShark (antes llamado Ethereal) para examinar paquetes en una red de datos. Redes de Datos - Laboratorio Objetivo WireShark Este instructivo describe el uso del programa WireShark (antes llamado Ethereal) para examinar paquetes en una red de datos. Analizadores de Protocolos de

Más detalles

Práctica 2: Configuración de interfaces IP en equipos con sistema operativo GNU/Linux

Práctica 2: Configuración de interfaces IP en equipos con sistema operativo GNU/Linux Práctica 2: Configuración de interfaces IP en equipos con sistema operativo GNU/Linux 1- Objetivos Para probar las configuraciones de redes necesitaremos PCs que colocaremos en las diferentes LANs. Por

Más detalles

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Marco teórico: La red más grande del mundo, Internet, ha tenido un gran crecimiento en la

Más detalles

Ampliación de Data Centers con Cisco Fabric Path

Ampliación de Data Centers con Cisco Fabric Path Informe técnico Ampliación de Data Centers con Cisco Fabric Path Qué aprenderá Las arquitecturas de redes tradicionales están diseñadas con el fin de ofrecer alta disponibilidad para las aplicaciones estáticas,

Más detalles

MS_10747 Administering System Center 2012 Configuration Manager

MS_10747 Administering System Center 2012 Configuration Manager Administering System Center 2012 Configuration Manager www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso describe cómo

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Redes de Computadoras Junio de 2006. Teoría y problemas (75 %)

Redes de Computadoras Junio de 2006. Teoría y problemas (75 %) Redes de Computadoras Junio de 2006 Nombre: DNI: Teoría y problemas (75 %) 1. (1 punto) Suponga una aplicación P2P de compartición de ficheros en la que existe un servidor central que ofrece un servicio

Más detalles

Encaminamiento de paquetes con IP

Encaminamiento de paquetes con IP PRÁCTICA 4 Encaminamiento de paquetes con IP REDES (9359) ING. TÉCNICA EN INFORMÁTICA DE SISTEMAS CURSO 2010/2011 (Este documento es una versión en papel de la versión completa en formato web-scorm publicada

Más detalles

Una ACL es una lista secuencial de sentencias de permiso o denegación que se aplican a direcciones IP o protocolos de capa superior.

Una ACL es una lista secuencial de sentencias de permiso o denegación que se aplican a direcciones IP o protocolos de capa superior. Listas de control de acceso o ACL. Listas de control de acceso o ACL. Una ACL es una lista secuencial de sentencias de permiso o denegación que se aplican a direcciones IP o protocolos de capa superior.

Más detalles

Una estructura de firewall en alta disponibilidad presenta las siguientes ventajas:

Una estructura de firewall en alta disponibilidad presenta las siguientes ventajas: NOTA. LOS EJEMPLOS BRINDADOS DEBEN SER CORREGIDOS PARA ADECUARLOS A VERSIONES DE OPENBSD 4.7 EN ADELANTE. CONSULTAR www.redklee.com.ar PARA AGREGADOS A ESTE DOCUMENTO. Esquema de firewall en alta disponibilidad

Más detalles

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos.

Contenidos. Sistemas operativos Tema 3: Estructura del sistema operativo. Componentes típicos de un SO. Gestión de procesos. Contenidos Sistemas operativos Tema 3: Estructura del sistema operativo Componentes típicos del SO Servicios del SO Llamadas al sistema Programas del sistema El núcleo o kernel Modelos de diseño del SO

Más detalles

Programas de Administración de red

Programas de Administración de red 1 Programas de Administración de red Introducción El propósito de las siguientes prácticas es el de familiarizar al alumno con los distintos programas que se utilizan para chequear y comprobar el estado

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Solución del examen de Redes - Segundo parcial - ETSIA - 1 de junio 2007

Solución del examen de Redes - Segundo parcial - ETSIA - 1 de junio 2007 Solución del examen de Redes - Segundo parcial - ETSIA - de junio 2007 Apellidos, Nombre: Grupo de matrícula:. (0,75 puntos) La captura mostrada en la figura siguiente se ha realizado desde un equipo del

Más detalles

Beneficios estratégicos para su organización. Beneficios

Beneficios estratégicos para su organización. Beneficios La solución ideal para controlar la totalidad de su infraestructura IT mediante un inventario automatizado, control remoto y Gestión de activos informáticos. Beneficios Características Inventario actualizado

Más detalles

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes 1 Objetivos Ingeniería Técnica Informática de Sistemas Curso 2003/2004 En la presente sesión se pretende familiarizar al alumno

Más detalles

Redes de Computadoras Introducción Arquitectura de Redes

Redes de Computadoras Introducción Arquitectura de Redes Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas Redes de Computadoras Introducción Arquitectura de Redes Mérida - Venezuela Prof. Gilberto Díaz Otra clasificación de las redes Según

Más detalles

Sistemas de Operación II

Sistemas de Operación II Sistemas de Operación II Procesos en Sistemas Distribuidos Prof. Yudith Cardinale Abril-Julio 2012 Contenido Hilos en Sistemas Distribuidos Clientes Servidores Anexo: Virtualización 2 Procesos e hilos

Más detalles

Servidor Cloud by cloudbuilder

Servidor Cloud by cloudbuilder Servidor Cloud by cloudbuilder Cómo funciona Cloud? De qué está hecha la Nube? Es segura? En qué se diferencia de los servicios tradicionales de hosting?... Descubre todas las posibilidades que te ofrece

Más detalles

En informática, un servidor es una computadora que, formando parte de una red, provee servicios a otras computadoras denominadas clientes.

En informática, un servidor es una computadora que, formando parte de una red, provee servicios a otras computadoras denominadas clientes. 14. Servidores En informática, un servidor es una computadora que, formando parte de una red, provee servicios a otras computadoras denominadas clientes.1 También se suele denominar con la palabra servidor

Más detalles

Título del contenido: Windows Server 2012 Detalles técnicos de redes

Título del contenido: Windows Server 2012 Detalles técnicos de redes Título del contenido: Windows Server 2012 Detalles técnicos de redes Módulo 3: Virtualización de red de Hyper-V Manual del módulo Autor: James Hamilton-Adams, Content Master Publicado: [introducir fecha]

Más detalles

Análisis de comunicaciones TCP/IP con Ethereal

Análisis de comunicaciones TCP/IP con Ethereal Taller Federico Lazcano flazcano@eie.fceia.unr.edu.ar Área Comunicaciones Escuela de Ingeniería Electrónica Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Página

Más detalles

Estudio de caso. Redes WAN. Programa de las Academias de Networking de Cisco CCNA 4: Tecnologías WAN v3.1

Estudio de caso. Redes WAN. Programa de las Academias de Networking de Cisco CCNA 4: Tecnologías WAN v3.1 Estudio de caso Redes WAN Programa de las Academias de Networking de Cisco CCNA 4: Tecnologías WAN v3.1 Descripción general y objetivos Este estudio de caso final permite que los estudiantes construyan

Más detalles

Gestión de Redes TCP/IP basada en RMON. Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu

Gestión de Redes TCP/IP basada en RMON. Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu Gestión de Redes TCP/IP basada en RMON Dra. Ing. Caridad Anías Calderón Cujae cacha@tesla.cujae.edu.cu Aspectos a tratar Introducción Características de RMON Ventajas del empleo de RMON Versiones de RMON

Más detalles

Ethereal. Este instructivo describe el uso del programa Ethereal para examinar paquetes en una red de datos.

Ethereal. Este instructivo describe el uso del programa Ethereal para examinar paquetes en una red de datos. Instituto de Ingeniería Eléctrica Redes de Datos. Objetivo. Ethereal Este instructivo describe el uso del programa Ethereal para examinar paquetes en una red de datos. Analizadores de Protocolos de Red.

Más detalles

Diseño de Campus LAN

Diseño de Campus LAN Fundamentos de Tecnologías y Protocolos de Red Diseño de Campus LAN Area de Ingeniería Telemática http://www.tlm.unavarra.es Grado en Ingeniería en Tecnologías de Telecomunicación, 3º Temario 1. Introducción

Más detalles

(Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un

(Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un (Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un compilador/intérprete y un depurador (localización de errores lógicos).

Más detalles

Concepto de Procesamiento Distribuido y Centralizado

Concepto de Procesamiento Distribuido y Centralizado Concepto de Procesamiento Distribuido y Centralizado Procesamiento Centralizado: En la década de los años 50 s las computadoras eran máquinas del tamaño de todo un cuarto con las siguientes características:

Más detalles

1.Introducción. 2.Direcciones ip

1.Introducción. 2.Direcciones ip 1.Introducción El papel de la capa IP es averiguar cómo encaminar paquetes o datagramas a su destino final, lo que consigue mediante el protocolo IP. Para hacerlo posible, cada interfaz en la red necesita

Más detalles

Universidad Autónoma de Nuevo León Facultad de Ciencias Físico Matemáticas. Laboratorio de Seguridad en aplicaciones web

Universidad Autónoma de Nuevo León Facultad de Ciencias Físico Matemáticas. Laboratorio de Seguridad en aplicaciones web Universidad Autónoma de Nuevo León Facultad de Ciencias Físico Matemáticas Laboratorio de Seguridad en aplicaciones web Practica 2: Configuración de VPN y escaneo de puertos. Objetivos: En esta práctica

Más detalles

Router Teldat. Interfaz PPPoE

Router Teldat. Interfaz PPPoE Router Teldat Interfaz PPPoE Doc. DM708 Rev. 10.00 Febrero, 2003 ÍNDICE Capítulo 1 Protocolo PPPoE...1 1. Introducción... 2 2. Descripción del protocolo PPPoE... 3 2.1. Fase de descubrimiento... 3 2.2.

Más detalles

Arquitectura de Redes y Sistemas de Telecomunicación

Arquitectura de Redes y Sistemas de Telecomunicación Práctica 0 Arquitectura de Redes y Sistemas de Telecomunicación Introducción al Wireshark Fundamentos del analizador de protocolos Wireshark. Objetivos En esta introducción se pretenden adquirir las capacidades

Más detalles

Manual de uso Packet Tracer 5

Manual de uso Packet Tracer 5 Manual de uso Packet Tracer 5 ELO 324 - Laboratorio de Redes y Sistemas Operativos Profesor Miguel Rebolledo Marzo 2011 Indice Introducción.. 3 Objetivos.. 3 Primeros Pasos. 4 Posicionamiento de los Dispositivos..

Más detalles

Filtrado de paquetes y NAT

Filtrado de paquetes y NAT Semana 9: Firewalls Filtrado de paquetes y NAT Aprendizajes esperados Contenidos: Filtrado de paquetes NAT Filtrado de paquetes Un # ping c 1 127.0.0.1 Filtrado de paquetes Cada regla especifica un conjunto

Más detalles

Infraestructura de redes empresariales Cisco ONE: la base automatizada y centrada en las aplicaciones para la empresa moderna

Infraestructura de redes empresariales Cisco ONE: la base automatizada y centrada en las aplicaciones para la empresa moderna Informe técnico Infraestructura de redes empresariales Cisco ONE: la base automatizada y centrada en las aplicaciones para la empresa moderna El reto Se ha producido un enorme cambio en las empresas en

Más detalles

Marco Teórico MARCO TEÓRICO. AGNI GERMÁN ANDRACA GUTIERREZ

Marco Teórico MARCO TEÓRICO. AGNI GERMÁN ANDRACA GUTIERREZ MARCO TEÓRICO. 13 14 Virtualización Hablar de virtualización es hablar de un concepto que describe la posibilidad de tener varios sistemas operativos funcionando al mismo tiempo en un mismo equipo físico.

Más detalles

Gráficos de tráfico y estadísticas usando MRTG

Gráficos de tráfico y estadísticas usando MRTG Gráficos de tráfico y estadísticas usando MRTG La presentación de gráficos estadísticos para evaluar el uso del ancho de banda a Internet se considera una característica opcional de un router; sin embargo,

Más detalles

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores

REPORTE OFICIAL OCTUBRE DE 2014. CA Unified Infrastructure Management para servidores REPORTE OFICIAL OCTUBRE DE 2014 CA Unified Infrastructure Management para servidores 2 Reporte oficial: CA Unified Infrastructure Management para servidores Tabla de contenidos Descripción general de la

Más detalles

Estos requisitos son específicos para ciertos tipos de redes y más generales en otros tipos de redes.

Estos requisitos son específicos para ciertos tipos de redes y más generales en otros tipos de redes. Objetivos y componentes de diseño LAN 1- Objetivos del diseño LAN El diseño de una red puede ser una tarea fascinante e implica mucho más que simplemente conectar computadores entre sí. Una red requiere

Más detalles

Examen de Arquitectura de Redes Sistemas y Servicios (Teoría) 3 o Ingeniería de Telecomunicación Mayo 2011

Examen de Arquitectura de Redes Sistemas y Servicios (Teoría) 3 o Ingeniería de Telecomunicación Mayo 2011 Nombre y apellidos: DNI: 1 Examen de Arquitectura de Redes Sistemas y Servicios (Teoría) 3 o Ingeniería de Telecomunicación Mayo 2011 Test previo: Duración: 0.5 horas. Se permiten libros y apuntes. Pregunta

Más detalles

PRACTICA 3. Monitorización de redes mediante Analyzer Justificación y objetivos. El paquete Analyzer

PRACTICA 3. Monitorización de redes mediante Analyzer Justificación y objetivos. El paquete Analyzer PRACTICA 3 Monitorización de redes mediante Analyzer Justificación y objetivos. La monitorización de redes resulta una herramienta fundamental en dos sentidos. Por un lado, permite apreciar de forma realista

Más detalles

http://marabunta.laotracara.com http://enjambre.laotracara.com

http://marabunta.laotracara.com http://enjambre.laotracara.com http://marabunta.laotracara.com http://enjambre.laotracara.com David Gascón Cabrejas david@laotracara.com http://www.laotracara.com Perspectiva Inicial Qué es Marabunta? Qué servicios ofrece actualmente

Más detalles

Respaldo y recuperación en ambientes VMware con Avamar 6.0

Respaldo y recuperación en ambientes VMware con Avamar 6.0 Informe técnico Respaldo y recuperación en ambientes VMware con Avamar 6.0 Análisis detallado Resumen Dado el ritmo cada vez más rápido de la implementación de ambientes virtuales en la nube de la compañía,

Más detalles

Windows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services.

Windows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services. Windows Server 2012: Identidad y Acceso Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services. Manual del Módulo Autor: Andrew J Warren, Content Master Publicado: Septiembre 10 de

Más detalles

Internet Firewalls Linux ipchains.

Internet Firewalls Linux ipchains. Internet Firewalls Linux ipchains. I Parte. Firewalls Introducción. Actualmente, Internet es la principal vía para consultar y publicar información de una forma sencilla, económica y revolucionaria. Del

Más detalles

Capa de red en Internet

Capa de red en Internet Capa de red en Internet Una colección de Sistemas Autónomos (AS) Algunos backbones (espina dorsal, corazón de la red) formados por proveedores de nivel más alto Lo que los une es el Protocolo IP Necesidad

Más detalles

Laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo

Laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo Laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo Objetivos de aprendizaje Poder explicar el propósito de un analizador de protocolos (Wireshark). Poder realizar capturas

Más detalles

Redes I Soluciones de la Práctica 1: /etc/network/interfaces, tcpdump y wireshark

Redes I Soluciones de la Práctica 1: /etc/network/interfaces, tcpdump y wireshark Redes I Soluciones de la Práctica 1: /etc/network/interfaces, tcpdump y wireshark Universidad Rey Juan Carlos Curso 2007/2008 Resumen Los primeros cuatro apartados de la práctica consisten en replicar

Más detalles

Práctica de laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo

Práctica de laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo Práctica de laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo Objetivos de aprendizaje Poder explicar el propósito de un analizador de protocolos (Wireshark). Poder realizar

Más detalles

Monitoreo de Nubes Privadas

Monitoreo de Nubes Privadas Monitoreo de Nubes Privadas Whitepaper Autores: Dirk Paessler, CEO de Paessler AG Gerald Schoch, Editor Técnico de Paessler AG Publicado: Mayo 2011 Ultima Actualización: Febrero 2015 PÁGINA 1 DE 7 Contenido

Más detalles

Arquitectura de redes empresariales Cisco ONE: una base automatizada de reconocimiento de aplicaciones para la empresa moderna

Arquitectura de redes empresariales Cisco ONE: una base automatizada de reconocimiento de aplicaciones para la empresa moderna Informe técnico Arquitectura de redes empresariales Cisco ONE: una base automatizada de reconocimiento de aplicaciones para la empresa moderna El desafío Las empresas presenciaron cambios masivos durante

Más detalles

Habiendo hecho esta salvedad, comencemos por definir Qué es IP?

Habiendo hecho esta salvedad, comencemos por definir Qué es IP? APUNTE BÁSICO SOBRE REDES IP Es necesario conocer los conceptos básicos sobre IP ya que es la tecnología y el canal de comunicación esencial que IP-400 utiliza para todas sus interacciones con el mundo

Más detalles

MSP Dashboard. Guía de soluciones

MSP Dashboard. Guía de soluciones Guía de soluciones MSP Dashboard Este documento presenta MSP Dashboard (panel de servicios gestionados) de Cisco Meraki, que contiene características a medida para que los proveedores de servicios gestionados

Más detalles

Práctica 7 Network Address Translation en routers Cisco

Práctica 7 Network Address Translation en routers Cisco Práctica 7 Network Address Translation en routers Cisco 1- Objetivos NAT permite que una red IP parezca hacia el exterior que emplea un espacio de direcciones diferente del que en realidad usa. La utilidad

Más detalles

Laboratorio de Router Estático Laboratorio de Redes 2

Laboratorio de Router Estático Laboratorio de Redes 2 Laboratorio de Router Estático Laboratorio de Redes 2 Profesor: Diego Aracena Pizarro PARTE I Armar una red doméstica (PC Router con Ubuntu o Linux) La figura 1 muestra la topología de red ha utilizar

Más detalles

CENTRO DE DATOS Y POP

CENTRO DE DATOS Y POP Virtual y física. Pública y privada. Por horas o por meses. Nuestra plataforma unificada proporciona infraestructuras en la nube a nivel de Internet. Todo lo que quiera, desplegado bajo demanda y en tiempo

Más detalles

Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet

Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet 7.5 Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet 1 2 3 3 4 Hay dos motivos fundamentales para dividir una LAN en segmentos. El primer motivo es aislar

Más detalles

Optimización de la asignación de direcciones IP

Optimización de la asignación de direcciones IP Optimización de la asignación de direcciones IP Contenido Descripción general 1 Claseless Inter-Domain Routing (CIDR) 2 Direcciones IP binarias 5 Máscaras de subred binarias 10 Asignación de direcciones

Más detalles

Redes de Computadoras Introducción

Redes de Computadoras Introducción Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas Redes de Computadoras Introducción Mérida - Venezuela Prof. Gilberto Díaz Compartiendo Recursos En la clase anterior vimos ciertas características

Más detalles

CAPITULO III. TECNOLOGÍA SNMP

CAPITULO III. TECNOLOGÍA SNMP CAPITULO III. TECNOLOGÍA SNMP En este capitulo haremos una presentación sobre la estructura básica del protocolo de monitoreo SNMP. El objetivo de este protocolo es poder realizar un monitoreo del estado

Más detalles

CCNA 1 - Examen final

CCNA 1 - Examen final CCNA 1 - Examen final 1. Se refieren a la exposición. B acogida a los intentos de establecer una red TCP / IP con el período de sesiones de acogida C. Durante este intento, uno fue capturado en el marco

Más detalles

Diseño y configuración de redes IP

Diseño y configuración de redes IP Contenido Tema 8 Diseño y configuración de redes IP Protocolos de encaminamiento Características Sistemas autónomos IGP: RIP y OSPF EGP: BGP Segunda parte 1 Ampliación interconexión de redes: Conmutadores

Más detalles

6. Grandes Soluciones.

6. Grandes Soluciones. 6. Grandes Soluciones. 6.1. Hewlett Packard. La estrategia de HP en SDN ha sido la de mantener en sus equipos la compatibilidad con el protocolo OpenFlow. Entre los grandes fabricantes aparecen dos filosofías,

Más detalles