OSPF con Quagga en una red virtualizada Juan Segovia, Junio 2012

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

Download "OSPF con Quagga en una red virtualizada Juan Segovia, Junio 2012 jsegovia@eia.udg.edu"

Transcripción

1 Juan Segovia, Junio Resumen En este documento se describe en general el proceso y los resultados de poner en operación una simple red con enrutamiento OSPF. En internet puede encontrarse una gran cantidad de materiales que abordan el tema de enrutamiento OSPF. Sin embargo, en la mayoría de los casos la red considerada no incluye redundancia, es decir, las topologías usadas tienen a ser árboles o simples líneas. En tales casos, la reconfiguración simplemente no se da, pues una parte de la red queda inaccesible. Estas pruebas se realizan en una red de cinco enrutadores. Sin embargo, la red se implementa en forma virtualizada, en un único servidor Linux. En este resumen mencionamos los principales aspectos que se deben configurar en los enrutadores (que a su vez son sistemas Linux con Quagga) y se describen con cierto detalle algunos problemas que se encontraron y que son específicos de Linux básicamente, el fallo de herramientas clásicas como traceroute, necesidad de cambiar variables del kernel (sysctl) y también de la plataforma de virtualización. El escenario es minimalista (una sola área OSPF, no interrelación con otros protocolos de enrutamiento (por ejemplo, BGP), no enlaces virtuales), pero en cualquier caso, la experiencia muestra que es viable hacer este tipo de experimentos en un entorno virtualizado, incluso con pocos recursos en el host real (en nuestro caso, usamos el servidor adcx3.udg.edu). Tabla de contenido 1. Resumen Diseño de la red Configuración de Linux Paquetes de software de Linux Configuraciones básicas de red en Linux Configuración de NAT en ospf Configuración de sysctl Implementación virtualizada de la red Enrutadores Switches... 7 Switches usando brctl...7 Switches usando VDE...8 El dispositivo veth Configuración de Quagga Acceso a la consola de Quagga Contenido de los archivos de configuración Anuncio de la ruta por defecto al exterior Puesta a punto y verificación de funcionamiento Configuración de NAT en el servidor real...11 Página 1/28

2 6.2. Pruebas básicas de las tablas de rutas y de conectividad Cuidado con lo que traceroute nos cuenta Pruebas de re-enrutamiento ante fallos...13 Cómo generar fallos...13 Rutas directas a todas las interfaces de los enrutadores...14 Timers de OSPF Observaciones sobre rp_filter KVM y redes virtualizadas: algunas lecciones Anexo de archivos de configuración y scripts Configuración de Linux Quagga Scripts Recursos Diseño de la red La red elegida para estos experimentos se muestra en la Fig. 1. Cada uno de los nodos identificados como ospf# representa un enrutador que provee acceso/servicio a una red local (no mostrada en la figura). Las direcciones de estas redes locales son anunciadas por los enrutadores ospf# de tal manera que cualquier computador de toda la red tiene conectividad a cualquier otro, sea de la red local que fuera. El enrutamiento se realiza vía OSPF, protocolo que se ejecuta en todos los enrutadores ospf#, agrupados en una sola área (el backbone). UdG / Internet gw ospf1 ospf2 ospf5 ospf3 ospf4 Fig. 1. Topología de la red usada en los experimentos En enrutador identificado como gw no ejecuta OSPF. Su función es dar acceso a la red UdG e internet a todos los computadores del anillo. El enrutador ospf1 inyecta esta ruta por defecto para beneficio de los computadores del anillo. Página 2/28

3 Dada su estructura, la red es tolerante al fallo de un enlace (single failure), por lo que el sistema de enrutamiento debe garantizar que el cambio en la topología sea conocida por todos y que la conectividad IP se restablezca en poco tiempo. Asimismo, si desapareciera un nodo OSPF, los restantes nodos y sus clientes deben poder continuar comunicándose. Los enlaces son, en principio, Ethernet de 100 Mbps, pero podrían ser de cualquier otra velocidad (o tecnología de transmisión, por ejemplo, conexiones seriales usando PPP). Por otra parte, es posible ampliar la topología para que ya no sea estrictamente un anillo, pero se lo deja tal cual para mantener la simplicidad con redundancia (agregar otro nodo fuera del anillo implicaría que este nuevo nodo debe también tener al menos grado dos). 3. Configuración de Linux La implementación de OSPF utilizada es Quagga, versión El sistema operativo es Ubuntu Linux LTS (x86, 32 bits), con kernel En cualquier caso, no se ha detectado ninguna dependencia concreta respecto a la versión del sistema (kernel y utilitarios) o del software de enrutamiento. Los sysctl de Linux que se ajustan para estas pruebas existen desde al menos la versión 2.6 del kernel. La Fig. 2 muestra la red completa, ya con el esquema de numeración IP utilizado. La red que conforma el anillo utiliza números /24, mientras que la red de conexión al gateway externo es /24. Los números IP que en la figura aparecen subrayados son usados como router-id. Por otra parte, los clientes locales a cada enrutador OSPF usan IPs del rango NN.0/24, donde NN se sustituye por los dos últimos dígitos del router-id. Debe mencionarse que la red de los clientes locales de cada enrutador no se configura (no existe), ni siquiera la interfaz de red que los conectaría (líneas punteadas finas), y mucho menos los switches. A través de mecanismos simples que se explican más adelante, se anuncia cada red NN.0/24 vía OSPF para facilitar la inspección del correcto funcionamiento del enrutamiento cuando hay cambios en la topología Paquetes de software de Linux Los paquetes usados en Ubuntu son: quagga (y sus dependencias, que son pocas) traceroute iputils-ping iputils-tracepath vim (o algún otro editor de archivos de texto) 3.2. Configuraciones básicas de red en Linux Una premisa de trabajo es que se desea mantener las configuraciones de Quagga y de Linux lo más sencilla posibles; concretamente, se desea dejar el mayor número posible de configuraciones en sus valores por defecto. Los enrutadores ospf2 a ospf5 usarán una configuración similar a la siguiente: Página 3/28

4 gw / / / / /24 Fig. 2. Esquema de numeración IP de la red de prueba. Los números IP subrayados son usados como router-id. Las líneas punteadas finas corresponden a la interfaz ficticia /etc/network/interfaces auto lo iface lo inet loopback auto eth0 auto eth1 Como ospf1 tiene una interfaz adicional, se debe además poner lo que a continuación se indica. Nótese que aquí se decidió configurar esta interfaz estáticamente vía Linux, pero también se puede hacerlo vía Quagga. La ventaja de dejarlo del lado de Linux es que en un solo lugar se está configurando tanto la ruta por defecto (gateway) como los servidores DNS (/etc/resolv.conf se genera automáticamente). # Continuación de /etc/network/interfaces; # solo para ospf1 auto eth2 iface eth2 inet static address netmask gateway dns-nameservers /etc/hosts # ospf2, ospf3, o lo que corresponda localhost ospf2 Además, si cada ospf# se crea a partir de una copia única, conviene ajustar el hostname: Página 4/28

5 /etc/hostname ospf2 En los demás enrutadores (ospf2 al osp5) conviene tener lo siguiente: /etc/resolv.conf nameserver nameserver Configuración de NAT en ospf1 Los enrutadores ospf2 a ospf5 se quedan con la configuración por defecto de iptables, que debe ser de aceptar todo. Sin embargo, ospf1 debe realizar NAT para el resto de la red. Para lograr esto, se crea el siguiente archivo (el nombre no tiene importancia): /etc/iptables.conf *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] # NAT para IP /16 -A POSTROUTING -s /16! -d /16 -p tcp -j MASQUERADE --to-ports A POSTROUTING -s /16! -d /16 -p udp -j MASQUERADE --to-ports A POSTROUTING -s /16! -d /16 -j MASQUERADE COMMIT Además, se debe copiar el script iptables_udg (ver anexos) a /etc/init.d y activar su ejecución automática al iniciar el sistema: $ sudo update-rc.d iptables_udg enable 3.4. Configuración de sysctl Los siguientes sysctls son esenciales para el buen funcionamiento de la recuperación (re-enrutamiento) en el anillo. La conjunción de estos valores particulares se ha probado que funciona para este caso concreto. En internet se pueden encontrar otras variantes, para otros casos de usos (para load balancing, por ejemplo). /etc/sysctl.conf net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0 net.ipv4.ip_forward=1 Con los valores por defecto de Ubuntu, el comportamiento del enrutamiento es caótico (depende de qué nodo se pruebe, de se se reinicia o no Quagga,...), contradictorio (traceroute versus tracepath) o simplemente los servicios fallan (un cliente SSH termina abruptamente, con la comunicación cortada bien al inicio), a pesar de que a nivel de Página 5/28

6 enrutamiento o ICMP (ping por ejemplo) todo parece estar bien. Nótese que la misma variable aparece tanto bajo.all como.default. Esto se ha encontrado que es esencial. Supuestamente (http://forum.openvz.org/index.php? t=msg&goto=3144),.all se usa para afectar a las interfaces presentes al momento de realizarse el cambio (y también cambia la correspondiente variable bajo.default), mientras que.default afecta a futuras interfaces (por ejemplo, un controlador wifi USB, que no es nuestro caso). Para estas pruebas, en un primer momento, se configuró solo.all, ya que debería ser suficiente, pero en la práctica se ha visto que no lo es. Estas variables y los efectos de cada valor posible se describen con relativo detalle en la documentación del kernel de Linux: La sección 8 contiene observaciones adicionales sobre la variable rp_filter, y un breve ejemplo de por qué falla el (re)enrutamiento con el valor por defecto. 4. Implementación virtualizada de la red Los enlaces entre cada par de nodo se implementan según se muestra en la Fig. 3. Como puede verse, el enrutador OSPF es en verdad un PC con sistema operativo Linux con (al menos) dos interfaces de red; la conexión física se materializa a través de un switch. Sin embargo, todos estos elementos son virtuales: los computadores que harán de enrutadores y también el switch. La virtualización se realiza en adcx3.udg.edu, un servidor con 8 cores, Ubuntu Linux Server, en modo x64 y 8 GB de RAM. El software de virtualización es KVM/QEMU. A partir de ahora, usaremos simplemente KVM para referirnos la combinación de ambos paquetes. A continuación se provee información sobre los mecanismos usados para implementar la red virtual, incluyendo scripts desarrollados para el efecto. Se asume que las imágenes de los discos duros, los scripts y archivos de configuración se encuentran en un directorio específico. En nuestro caso, en adcx3 se usó /extra/kvm como raíz Enrutadores Los computadores virtualizados tienen las siguientes características principales: Tipo: PC standard de 32 bits, de un solo procesador RAM: 256 MB Disco: imagen de 20 GB; uso efectivo, aproximadamente 6 GB. Controlador, del tipo virtio (tambén se ha probado con IDE/ATA ). NIC: del tipo virtio (también se ha probado con e1000 y rtl8139; todos funcionan correctamente). Cada NIC recibe un MAC generado aleatoriamente al iniciar el computador virtualizado. El enrutador ospf1 tiene tres tarjetas, y los demás dos. Sistema operativo: Ubuntu Linux 12.04, de 32 bits. La cantidad de RAM señalada es la mínima con la que se puede iniciar el sistema; con menos, el kernel aborta al iniciar. Esta cantidad de RAM es exagerada para tan poco. Sin embargo, la imagen de disco usada como base corresponde a una instalación Página 6/28

7 Dos nodos adyacentes se conectan a través de un switch Switch Ethernet PC con 2 NIC Ethernet; Quagga sobre Linux Fig. 3. Cada enlace de la topología se implementa con un switch previa, de estación de trabajo, por lo que es de suponer que hay una serie de programas y configuraciones que obligan a una mayor disponibilidad de recursos (RAM y disco) de lo que haría falta si se hiciese una instalación desde cero. Existen varios front-end (GUI) para KVM, pero en este caso se ha optado por utilizar unos Shell scripts simples, que permiten configurar toda la red virtual con relativa facilidad. Se asume que existe un script (casi unilínea) que inicia cada máquina virtual. Un ejemplo de activación es: $ sudo sh bin/kvm_ospf2.sh con lo que se abre una ventana que inicia el arranque del sistema, como lo hace habitualmente Linux. El acceso al servidor virtualizado es a través de una consola en modo texto normal. El anterior script y los demás se incluyen en anexo Switches Se han probado dos implementaciones de switches: una basada en los bridges del sistema base, y otro llamado VDE (http://vde.sourceforge.net/). Recordemos que en nuestro caso concreto solo nos interesa crear enlaces punto a punto, por lo que un simple cable cross over Ethernet ya sería suficiente (no necesitamos un switch). Sin embargo, en este punto se depende de lo que KVM soporten. Para el caso que nos ocupa, las opciones son los dispositivos tap y los switches vde (KVM soporta otros tipos de networking, que no nos sirven o que no son convenientes). Los switches se crean y destruyen en el script bin/switches.sh (con los parámetros start o stop). El tipo que se creará (con vde o con bridges) depende de una configuración que se cambia en bin/config. SWITCHES USANDO BRCTL Se debe tener instalado el paquete bridge-utils. A grandes rasgos, para intercomunicar dos instancias de KVM usando los bridges virtuales de Linux se debe (obsérvese la Fig. 1 para comprender la nomenclatura siguiente): Página 7/28

8 Crear un bridge y darle un nombre, digamos sw1 Crear dos interfaces Ethernet virtuales, que también deben tener nombres (ver más abajo la nomenclatura usada) Agregar ambos dispositivos tap al switch sw1 Hay que notar que necesitamos un switch (o hub), y en ningún momento haremos bridging, ni el en espacio virtualizado ni con el hardware real. Este no es el uso habitual de los bridges virtuales en Linux; se lo suele usar más bien para hacer bridging entre una tarjeta física (real) y una o más tarjetas de servidores virtuales. Como en ningún momento estas interfaces se usarán para intercambiar datos con la máquina real (la excepción es ospf1), deben quedar sin números IP, aunque sí en estado UP. La nomenclatura es la siguiente: Los switches se llaman sw1..sw5. El 1 corresponde al que está entre ospf1 y ospf2; sw2 está entre ospf2 y ospf3, y así sucesivamente. Los dispositivos tap se numeran tapnn, donde NN son los dos últimos dígitos del número IP de la interfaz que corresponde a los enrutadores a los que irán asociados. Así, para ospf3 se crearán tap22 y tap32, para ospf4 serán tap33 y tap43, etc. Bajo este esquema, se tendrán 16 interfaces virtuales nuevas: Cinco correspondiendo a los switches (aparecen en ifconfig como una interfaz más, aunque nunca los utilizamos como tales) Once correspondiendo a NICs (dos por enrutador, más el tercero de ospf1). Para usar este modo de switches, se debe modificar bin/config: sw_type= br SWITCHES USANDO VDE Se debe tener instalado el paquete vde2, y también libvirt-bin. Este modo es significativamente más simple que el anterior. No se crea ninguna interfaz lógica para los enlaces internos de la red virtual. Simplemente, se ejecuta un daemon que implementa un switch Ethernet en user-space. VDE tiene muchas otras funcionalidades, entre ellas la de crear switches que abarcan más de un computador, por lo que el switch puede ser distribuido. Para usar este modo de switches, se debe modificar bin/config: sw_type= vde Para crear un enlace entre dos instancias de KVM, basta con indicar a KVM que el tipo de dispositivo de la interfaz es vde, pasándole además el socket que corresponde al switch que interese (cada demonio, al iniciarse, dos o tres sockets que se usan para gestionar el switch, así como para para el tránsito del dato propiamente). Página 8/28

9 EL DISPOSITIVO VETH Linux tiene un dispositivo virtual llamado veth (Virtual Ethernet) implementa de una forma más simple y directa enlaces punto a punto Ethernet. Este dispositivo ofrece dos interfaces lógicas Ethernet conectadas en modo cross-over, por así decirlo. Lastimosamente, KVM no tiene soporte ( aun?) para veth. Cuando lo tenga, la configuración de las redes virtuales como las usadas aquí será mucho más simple. 5. Configuración de Quagga Los archivos de Quagga van todos en /etc/quagga. Existe un archivo para cada servicio, como ser ospfd.conf y bpgd.conf. Existe también un zebra.conf, que sirve para configurar las interfaces, rutas globales y otros aspectos generales de Quagga. Ténganse en cuenta que Quagga obliga a que los comandos de OSPF vayan en ospfd.conf, lo de configuración IP de la interfaz vaya zebra.conf, etc. Por lo tanto, cada archivo introduce un ámbito que hace que el comando interface eth0 en uno admita diferentes subcomandos del que va en el otro Acceso a la consola de Quagga Existen varias formas de acceder a la configuración viva de Quagga y sus componentes. En estos ejemplos, accedemos siempre vía la consola general de Quagga. Esta es una consola interactiva, similar a la del IOS de Cisco. $ sudo vtysh Esto no requiere ningún password extra que el solicitaría sudo. Otra forma que usamos en los ejemplos, que es batch, es: $ sudo vtysh -c algun comando de quagga 5.2. Contenido de los archivos de configuración Los valores concretos que van en los archivos de configuración son diferentes para todos los enrutadores, pero la estructura es idéntica. A continuación se muestra y comenta completa la configuración de ospf3. Contenido de zebra.conf: hostname ospf3 password algunatexto enable password otrotexto interface lo ip address /8 ip address /32 interface eth0 ip address /24 link-detect Página 9/28

10 interface eth1 ip address /24 link-detect ip route /24 null0 (Las líneas referidas a passwords en este archivo se pueden ignorar en el modo en que lo utilizamos aquí: básicamente, como root). El alias sobre la interfaz de loopback, que en este ejemplo tiene el número IP /32, sirve de router-id; es decir, la asignación es implícita, basada en la lógica de Quagga (y también del IOS de Cisco) para la elección de router-id. En estas pruebas, no usamos un valor explícito para el parámetro router-id de OSPF, sino que dejamos que Quagga lo elija (será el IP más alto de los configurados para el loopback). Por sí mismo, y tal como lo usamos aquí, router-id no tiene ningún propósito especial, y podría ser cualquier otro valor. Sin embargo, al poner un alias sobre el loopback, esa red siempre de anuncia vía OSPF, esté o no activa la interfaz a la que lógicamente corresponde tal número (nótese que /32 está en el rango de la red de la interfaz eth1). El efecto neto es que este número siempre estará disponible (para hacer SSH por ejemplo al nodo) toda vez que haya al menos un camino para llegar al no. Por otra parte, cada enrutador declara su red de clientes ( /24 en este caso), como si estos estuvieran sobre la interfaz null0 (que no existe). El anuncio de esta ruta estática se especifica en ospfd.conf. Es esquema que usamos con los archivos ospfd.conf es el siguiente. Nuevamente, este corresponde a ospf3. hostname ospf3 password zebra router ospf network /24 area network /24 area redistribute static 5.3. Anuncio de la ruta por defecto al exterior Dada su función, ospf1 es ligeramente diferente. En ospfd.conf se debe agregar: default-information originate para que el default route que se configura asociado a la interfaz eth2 sea anunciada a los demás enrutadores OSPF. 6. Puesta a punto y verificación de funcionamiento Página 10/28

11 Asumamos que el tipo de switch usado es VDE. Se puede iniciar el switch y toda la red así: $ sudo sh bin/switches start $ for k in ; do sudo sh bin/kvm_ospf$k.sh &; done El comando ifconfig en el computador real (adcx) reportará los siguiente (abreviado): adcx3$ ifconfig eth0 Link encap:ethernet HWaddr 18:a9:05:6f:1f:44 inet addr: Bcast: Mask: lo tap0 virbr0 Link encap:local Loopback inet addr: Mask: Link encap:ethernet HWaddr 96:23:9e:ac:37:9e inet6 addr: fe80::9423:9eff:feac:379e/64 Scope:Link Link encap:ethernet HWaddr 96:23:9e:ac:37:9e inet addr: Bcast: Mask: La interfaz tap0 es parte del bridge virbr0. Esta interfaz se usa, a su vez, para realizar NAT del todo el tráfico de la red virtual que necesite salir afuera (por ejemplo, para instalar paquetes desde Internet, o simplemente para copiar configuraciones desde algún computador de la red internet de la UdG) Configuración de NAT en el servidor real Lo siguiente debe agregarse (o adaptarse) a la configuración de iptables en adcx3 (por ejemplo, en /etc/iptables.conf, asumiendo que se usa el mismo script iptables_udg ya mencionado antes). El carácter \ indica que la línea siguiente forma parte de la actual. *nat -F :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] # NAT para virtual hosts con IP x -A POSTROUTING -s /24! -d /24 -p tcp -j MASQUERADE to-ports \ A POSTROUTING -s /24! -d /24 -p udp -j MASQUERADE to-ports \ A POSTROUTING -s /24! -d /24 -j MASQUERADE COMMIT 6.2. Pruebas básicas de las tablas de rutas y de conectividad Ahora se puede hacer login en cualquiera de los ospf# (se requiere tener acceso a root en los servidores virtuales, directamente o vía sudo). ospf4$ netstat -nr Kernel IP routing table Página 11/28

12 Destination Gateway Genmask Flags MSS Window irtt Iface UG eth UG eth UG eth UGH eth U eth U eth UG eth UGH eth UGH eth UG eth UG eth U * UG eth UG eth1 El estado de los vecinos OSPF se puede mirar con: ospf4$ sudo vtysh -c "show ip ospf neighbor" Neighbor ID Pri State Dead Time Address Interface Full/DR s eth0: Full/Backup s eth1: El enrutador ospf4 es designated router (DR) en su relación con ospf3, pero es backup DR en su relación con ospf5, rol que viene determinado por los valores del parámetro router-id. En nuestro caso, al ser los enlaces básicamente punto a punto, estos roles no tienen ninguna importancia (de hecho, se puede configurar las redes como del tipo point-to-point, pero no lo hacemos para mantener las configuraciones tan simples y cortas como se pueda) Cuidado con lo que traceroute nos cuenta También podemos usar traceroute para observar visualmente el camino que se seguiría en la red para un par origen-destino específico. ospf4$ traceroute -n traceroute to ( ), 30 hops max, 60 byte packets ms ms ms ms ms ms ospf4$ traceroute -n traceroute to ( ), 30 hops max, 60 byte packets ms ms ms ms ms ms ms ms ms Mirando la topología, esto no tiene sentido: en número de saltos, es más conveniente ospf4 ospf3 ospf2 (dos saltos), versus ospf4 ospf5 ospf1 ospf2. No solo eso: la traza reportada por traceroute hasta el contradice lo que contiene la tabla de rutas del kernel. La explicación es que traceroute tiene un error: elige mal la interfaz de salida. Esto se discute en el siguiente URL (entre muchos otros, este en particular es del 2001). Página 12/28

13 Si en vez de traceroute usamos tracepath (paquete iputils-tracepath), veremos otro resultado: ospf4$ tracepath -n : ms pmtu : ms 1: ms 2: ms reached Resume: pmtu 1500 hops 2 back 63 Sin embargo, queda la duda de cuál efectivamente se usa para un tráfico real. Haciendo tcpdump en las interfaces que corresponden a y mientras se abre una sesión SSH a , se puede ver que el tráfico va por la segunda, es decir, como debiera. Supuestamente, tracepath es una versión más simple de traceroute, que además no requiere permisos de root. Sin embargo, tengo la impresión de que, en Linux, traceroute está en fase de olvido (no mantenido) Pruebas de re-enrutamiento ante fallos A continuación induciremos algunos fallos (de enlaces ) para ver cómo OSPF detecta y reacciona ante el fallo y recalcula las nuevas rutas. Como máximo, se producirá un (1) fallo concurrente, que es lo máximo que la topología puede soportar sin desconectarse. CÓMO GENERAR FALLOS En un entorno real, un fallo de enlace se provoca/simula simplemente retirando el cable de la tarjeta de red o del switch. El software (el driver el sistema operativo) puede detectar que ya no hay enlace, y el software de enrutamiento (Quagga u otro) puede tomar las acciones que correspondan. En el entorno virtualizado usado aquí, no se ha encontrado una forma equivalente de retirar el cable. Si se usa el switch vde, la única alternativa es realizar un es realizar ifconfig <interfaz> down de la interfaz que se desea que falle. Quagga detecta inmediatamente que la interfaz se inactiva y notifica a los vecinos. En cambio, cuando se usa el switch en modo br, se puede además desactivar las interfaces tap que correspondan al enlace que se quiere que falle. En la práctica, esto bloqueará el tráfico y por lo tanto OSPF dará por perdida la conectividad con el nodo vecino transcurrido el dead time. Para probar la actualización de las rutas, a continuación hacemos que falle la interfaz que corresponde a en ospf4, que es eth0: ospf4$ ifconfig eth0 down En unos segundos, la tabla de enrutamiento en ospf4 debe quedar como sigue: ospf4$ netstat -nr Kernel IP routing table Página 13/28

14 Destination Gateway Genmask Flags MSS Window irtt Iface UG eth UG eth UG eth UGH eth UG eth UGH eth U eth UG eth UGH eth UGH eth UG eth UG eth U * UG eth UG eth1 Es decir, se puede ver claramente que ahora, para todos los destinos, se pega la vuelta. Por ejemplo, se puede mirar el camino para llegar al vecino ospf3: ospf4$ tracepath -n : ms pmtu : ms 1: ms 2: ms 3: ms 4: ms reached Resume: pmtu 1500 hops 4 back 61 Igualmente, un tracepath a seguiría el mismo camino. RUTAS DIRECTAS A TODAS LAS INTERFACES DE LOS ENRUTADORES Supongamos ahora que la interfaz que corresponde a en ospf3 se desactiva, empezando de un estado en que todas las interfaces estaban activas. ospf3$ ifconfig eth0 down La conectividad con todas las demás, incluyendo el vecino ospf2, seguiría intacta. Sin embargo, si vamos ospf2 hacemos ping o tracepath al , no hay respuesta. Esta asimetría se da por el hecho de que, desde la perspectiva de ospf2, la red /24 sigue up, y además el número , no siendo un router-id, no tiene una ruta específica. Si se prefiriese que todos los IPs de las interfaces estuvieran siempre accesibles mientras haya conectividad, habría que agregar cada IP de enlace como alias del loopback de cada enrutador. Página 14/28

15 TIMERS DE OSPF En estas pruebas, el valor de dead time se dejó en su valor por defecto (40s). En la práctica, para una red local tan pequeña como ésta, es probable que convenga reducir ese valor, o el del parámetro hello-interval, ya que por defecto dead-time es 4 veces aquel. 7. Observaciones sobre rp_filter A continuación se realizan algunas observaciones sobre qué sucede con el re-enrutamiento OSPF cuando rp_filter no tiene el valor sugerido en este documento. 1 En Ubuntu Linux, al menos en la versión desktop usada con los enrutadores OSPF instalados para estas pruebas, el parámetro sysctl net.ipv4.conf.all.rp_filter tiene 1 como valor por defecto. La documentación del kernel dice lo siguiente al respecto: rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. Current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended. The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}. Default value is 0. Note that some distributions enable it in startup scripts. En Wikipedia, hay un resumen sobre Reverse Path Forwarding, que es lo que configura la variable rp_filter (http://en.wikipedia.org/wiki/reverse_path_forwarding). Sobre strict mode (unicast), dice esencialmente lo mismo que ip-sysctl.txt. Cuando se tiene una estación (o servidor) con una topología simple, o incluso si se usa OSPF en modo hoja (stub), la configuración por defecto de Ubuntu funciona. El problema surge cuando el tráfico para un destino en particular puede tener más de un camino (es decir, cuando la topología de la red no forma un árbol estático). Para ilustrar lo que sucede, asumamos que todos los enrutadores del ejemplo fueron 1 En un primer momento, había parecido que arp_ignore también jugaba un papel en el (no) funcionamiento, pero finalmente fue posible identificar que la causa del no funcionamiento se debía a que todas las interfaces de toda la red estaban (erróneamente) ubicadas en el mismo dominio de broadcast. Página 15/28

16 configurados para que rp_filter=1, el valor por defecto. La Fig. 4muestra la topología simplificada. En una situación donde no hay fallos, la tabla de rutas de ospf4 dirá que para llegar al IP , basta con depositar el tráfico en la interfaz de salida eth0 ( ). Si esta interfaz falla, ya vimos que el tráfico pega la vuelta, por lo que siguiente salto hacia será ospf5 ( ). Supongamos ahora que el enlace se recupera. Inmediatamente, ospf4 empezará a recibir los mensajes enviados a las direcciones de broadcast ( ) por osp3. Por lo tanto, osp4 sabe que existe ospf3 y que su IP es (y también su router-id). Nótese que la ruta en el kernel sigue la que era mientras existía el fallo. En esta etapa, si se mira el estado de la interfaz según el demonio ospfd de Quagga, se podrá ver algo como lo que sigue: ospf3$ sudo vtysh -c show ip ospf interface eth0 eth0 is up ifindex 3, MTU 1500 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST> Internet Address /24, Broadcast , Area No backup designated router on this network Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5 Hello due in 4.115s Neighbor Count is 1, Adjacent neighbor count is 0 El problema es que, con rp_filter=1, esto queda eternamente así: todo paquete IP cuyo origen sea de la red /24 y que no se reciba por la interfaz eth1 en ospf4, debe ser descartado, pues en este momento cualquier repuesta (el reverse path) no iría por la interfaz eth1 sino por eth0. La negociación que debe seguir en OSPF para establecer las adyacencias simplemente falla, pues ospf3 nunca recibe respuesta. Cuando se está en esta situación errónea, al mirar el estado de los vecinos, se suele ver algo como lo que sigue: ospf4$ sudo vtysh -c show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface Fig. 4. Visión simplificada de la topología para analizar por qué se debe desactivar el strict Reverse Path Forwarding Página 16/28

17 Full/DR s eth1: Init/DROther s eth0: En el otro lado (ospf3 en este caso), que ni puede detectar la presencia del vecino, el equivalente de la segunda entrada ni aparecerá. 8. KVM y redes virtualizadas: algunas lecciones Al inicio de estas pruebas, se observaba un comportamiento ilógico o inesperado en la red: cuando se activaba el último nodo que cerraba el círculo de la red principal, el tráfico empezaba a circular en forma infinita, lo que saturaba completamente la capacidad de procesamiento de cada nodo. Una manera de resolver este problema consistía en que exactamente uno de los switches del conjunto tuviera activada la opción de spanning tree protocol (STP). Pero incluso con esto, se observaba que una consulta ARP (ARP request, por ejemplo) recibía múltiples respuestas (uno por cada interfaz del sistema Linux destino). Inicialmente, este comportamiento se resolvió también haciendo que la variable sysctl arp_ignore fuera 1 en vez de 0, que es su valor por defecto. Todo lo anterior no tenía sentido, ya que se partía de que la red constituía un espacio enrutado, así que el tráfico recibido en una interfaz no es propagada a la otra a menos que haga falta, desde el punto de vista IP. Finalmente, se pudo determinar que la causa del problema estaba en la forma en que se activaban los servidores virtualizados, que en esencia era inicialmente así: kvm -m 256 -name "ospf2" \ -drive file="ospf1.qcow2",cache=writeback,if=virtio \ -net nic,model=virtio,macaddr=... -net tap,ifname=tap52,... \ -net nic,model=virtio,macaddr=... -net tap,ifname=tap12,... Esto tiene más de un problema. Primero, el orden de probing de los dipositivos en la máquina virtualizada puede variar, así que el primer NIC puede aparecer una vez como eth0 y otra como eth1. Por otra parte, con esta forma de invocar KVM, no hay forma de asociar el primer NIC con el dispositivo tap52, y el segundo con el tap12. En unas primeras pruebas, parecía comportarse siempre como lo deseaba, pero las cosas se complicaron con ospf1, que tiene tres NICs, ni siquiera todos con la misma forma de attach (dos primeros con VDE, el último con tap, por ejemplo). Lo más grave, sin embargo, es que con esta invocación, KVM pone a todas los NIC en un switch interno creado por él (eso se explica gráficamente en La idea era que el usuario pudiera crear VLANs separadas. Como en nuestra invocación no ponemos ningún tag de VLAN, todas las tarjetas creaban un único dominio de broadcast. Es más, al ir interconectando entre sí (a través del switch lógico) los pares de tarjetas, al final toda la red era un solo dominio de broadcast. La solución es usar opciones de la línea de comandos más recientes, que permiten asociar Página 17/28

18 explícitamente cada dispositivo tap con los dispositivos virtualizados, además de indicar claramente el orden de probing. Esquemáticamente, la activación queda así: kvm -m 256 -k -name "ospf2" \ -drive file="ospf2.qcow2",... \ -netdev type="$nic_a_cfg",id=net1 \ -netdev type="$nic_b_cfg",id=net2 \ -device tap,mac="...",netdev=net1,bootindex=1 \ -device tap,mac="...",netdev=net2,bootindex=2 Naturalmente, estas observaciones son específicas para KVM, sin embargo, es probable que similares situaciones se encuentren sea cual fuera la plataforma de virtualización utilizada. 9. Anexo de archivos de configuración y scripts A continuación, se muestra el contenido de los principales archivos de configuración de Linux y Quagga. Solo se incluye lo correspondiente a un enrutador, ya que los demás siguen el mismo esquema. Posteriormente, se listan los fuentes de los scripts y archivos de configuración usados para crear la red virtualizada e iniciar las máquinas virtuales. Nuevamente, los casos repetitivos se omiten Configuración de Linux # /etc/network/interfaces auto lo iface lo inet loopback auto eth0 auto eth1 # Para ospf1: # auto eth2 # iface eth2 inet static # address # netmask # gateway # dns-nameservers # /etc/sysctl.conf net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0 net.ipv4.ip_forward=1 # /etc/resolv.conf # Excepto en ospf1 nameserver Página 18/28

19 nameserver # /etc/iptables.conf # Solo en ospf1 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] # NAT para IP /16 -A POSTROUTING -s /16! -d /16 -p tcp -j MASQUERADE --to-ports A POSTROUTING -s /16! -d /16 -p udp -j MASQUERADE --to-ports A POSTROUTING -s /16! -d /16 -j MASQUERADE COMMIT 9.2. Quagga! /etc/quagga/zebra.conf hostname ospf3 password algunatexto enable password otrotexto interface lo ip address /8 ip address /32 interface eth0 ip address /24 link-detect interface eth1 ip address /24 link-detect ip route /24 null0! /etc/quagga/ospf3.conf hostname ospf3 password zebra router ospf network /24 area network /24 area redistribute static! -- Página 19/28

20 ! para ospf1, se debe agregar:! default-information originate! Scripts./bin/config # (c) 2012 Juan Segovia S. # # # # BEWARE: This is not a directly-runnable script. Instead, # its intended purpose is to set global variables. Users # will "source" it, thus, it must not call exit. sw_type="vde" # The items in cfg have the following format: # switch_id(list_of_tap_interfaces) # # The switch id MUST be an integer. # The tap interfaces are used only by br_start/stop, not by vde. # For vde, put an empty list of "tap" interfaces; see example below. cfg="" case "$sw_type" in br) cfg="1(12 13) 2(22 23) 3(32 33) 4(42 43) 5(52 53)" # Extra interface config can be put here. #sw5_ip=" netmask broadcast " ;; vde) cfg="1() 2() 3() 4() 5()" vde_run_dir="/tmp" # Extra switch config can be put here. #vde_sw1_args="--fstp" ;; *) echo "** ERROR: Wrong value ($sw_type) in config for sw_type" >&2 esac./bin/switches.sh #! /bin/sh # ex: set tabstop=3: Página 20/28

LABORATORIO DE REDES PRÁCTICA 1 COMANDOS BÁSICOS PARA LA CONFIGURACIÓN DEL NIVEL IP EN UNA RED DE SISTEMAS UNIX. 1. LA INTERFAZ loopback

LABORATORIO DE REDES PRÁCTICA 1 COMANDOS BÁSICOS PARA LA CONFIGURACIÓN DEL NIVEL IP EN UNA RED DE SISTEMAS UNIX. 1. LA INTERFAZ loopback LABORATORIO DE REDES PRÁCTICA 1 COMANDOS BÁSICOS PARA LA CONFIGURACIÓN DEL NIVEL IP EN UNA RED DE SISTEMAS UNIX 1. LA INTERFAZ loopback La primera interfaz que es necesario activar al configurar el nivel

Más detalles

Introducción a las redes TCP/IP en Linux

Introducción a las redes TCP/IP en Linux Diseño y Administración de Sistemas y Redes Juan Céspedes Curso 2005 2006 Subsistema de red 1 Subsistema de red Los subsistemas más importantes del kernel de Linux son: gestión

Más detalles

Manual de utilización de Proxmox

Manual de utilización de Proxmox Manual de utilización de Proxmox Introducción Proxmox es una distribución de virtualización que ofrece la posibilidad de gestionar servidores virtuales (VPS) con tecnologías OpenVZ y Linux KVM al mismo

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

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

Lab 4: Routing Dinámico - OSPF José Mª Barceló Ordinas

Lab 4: Routing Dinámico - OSPF José Mª Barceló Ordinas 1. OSPF 1. 1. Configuración básica en un área Para configurar el algoritmo de encaminamiento OSPF en un área (por ejemplo el área 0), los pasos a seguir son los siguientes: 200.0.1.0/24 Consola Usamos

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

Introducción a NetGUI

Introducción a NetGUI Introducción a NetGUI Redes I Departamento de Sistemas Telemáticos y Computación (GSyC) Septiembre de 2011 GSyC - 2011 Introducción a NetGUI 1 c 2011 Grupo de Sistemas y Comunicaciones. Algunos derechos

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

Guía de configuración de tarjetas de red en Opensuse 12.3

Guía de configuración de tarjetas de red en Opensuse 12.3 Guía de configuración de tarjetas de red en Opensuse 12.3 Contenido de la guía CONTENIDO DE LA GUÍA... 1 1. CONCEPTOS GENERALES DE LAS TARJETAS DE RED EN LINUX... 2 2. CONFIGURACIÓN DE RED UTILIZANDO BRIDGE...

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

Configuración del encaminamiento en Linux

Configuración del encaminamiento en Linux Configuración del encaminamiento en Linux Departamento de Sistemas Telemáticos y Computación (GSyC) http://gsyc.urjc.es Febrero de 2012 GSyC - 2012 Configuración del encaminamiento en Linux 1 c 2012 GSyC

Más detalles

UNIDAD DIDACTICA 11 CONFIGURACIÓN DE LA RED EN GNU/LINUX

UNIDAD DIDACTICA 11 CONFIGURACIÓN DE LA RED EN GNU/LINUX UNIDAD DIDACTICA 11 CONFIGURACIÓN DE LA RED EN GNU/LINUX Eduard Lara 1 1. INTRODUCCIÓN En este capítulo recorreremos los pasos necesarios para configurar el protocolo TCP/IP en una máquina: Asignación

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 CONFIGURACIÓN BÁSICA DE REDES Sesión Configuración de routers Laboratorio 2.7 Material utilizado PCs, PC Routers y Routers Linksys

Más detalles

SERVICIOS. UF 1- Servidor DHCP

SERVICIOS. UF 1- Servidor DHCP SERVICIOS UF 1- Servidor DHCP -Enrutando mediante virtualbox y la IPTABLES: En el ordenador anfitrion tendrá una maquina virtual con linux server, y este estara conectado a la red del amfitrion, y aparte

Más detalles

NetGUI: 2. Configuración de RIP en Zebra

NetGUI: 2. Configuración de RIP en Zebra NetGUI: 2. Configuración de RIP en Zebra Sistemas Telemáticos I Departamento de Sistemas Telemáticos y Computación (GSyC) Marzo de 2010 GSyC - 2010 NetGUI: 3. Configuración de RIP en Zebra 1 c 2010 Grupo

Más detalles

Network Configuration

Network Configuration Page 1 of 5 Network Configuration Preguntas A title Question 1 Cuál de las siguientes podría ser una interfaz de red Ethernet de Linux? A. lo B. eth2 C. net0 D. tr1 E. neta Question 2 Qué comando se utiliza

Más detalles

Práctica de laboratorio: configuración de OSPFv3 básico de área única Topología

Práctica de laboratorio: configuración de OSPFv3 básico de área única Topología Práctica de laboratorio: configuración de OSPFv3 básico de área única Topología 2014 Cisco y/o sus filiales. Todos los derechos reservados. Este documento es información pública de Cisco. Página 1 de 11

Más detalles

Introducción a NetGUI

Introducción a NetGUI Introducción a NetGUI Redes I Departamento de Sistemas Telemáticos y Computación (GSyC) Septiembre de 2010 GSyC - 2010 Introducción a NetGUI 1 c 2010 Grupo de Sistemas y Comunicaciones. Algunos derechos

Más detalles

ADMINISTRACION DE REDES PARA INICIADOS

ADMINISTRACION DE REDES PARA INICIADOS ADMINISTRACION DE REDES PARA INICIADOS Acoplar una red local a Linux es fácil. Solo necesitamos tarjetas de red ethernet en cada ordenador, los cables apropiados y algun accesorio mas. La relación actual

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

Manual de utilización de Proxmox

Manual de utilización de Proxmox Buscar Manual de utilización de Proxmox ir Introducción Volver a lista de artículos Virtualización KVM Importar una ISO Crear una VM KVM en modo bridge... Proxmox es una distribución de virtualización

Más detalles

TEMA 0. Revisión Protocolo IPv4

TEMA 0. Revisión Protocolo IPv4 REDES Grados Ing. Informática / Ing. de Computadores / Ing. del Software Universidad Complutense de Madrid TEMA 0. Revisión Protocolo IPv4 PROFESORES: Rafael Moreno Vozmediano Rubén Santiago Montero Juan

Más detalles

2. Reiniciamos el modulo qemu-kvm, este carga sin problemas. /etc/init.d/qemu-kvm restart

2. Reiniciamos el modulo qemu-kvm, este carga sin problemas. /etc/init.d/qemu-kvm restart Bitácora diaria de avances Fecha Inicio: 20/03/2012 Fecha Fin: 10/04/2012 Autor: Camilo Andrés Botero C. Responsabilidad: Virtualización Centro de datos Spin off. Objetivo: Instalar KVM en el servidor

Más detalles

8. Cortafuegos (Firewall).

8. Cortafuegos (Firewall). 8.1. Introducción 8. Cortafuegos (Firewall). En la unidad anterior hemos visto como implementar un servidor proxy con el que podamos controlar los accesos a Internet. Ahora veremos como con un firewall

Más detalles

Laboratorio 1 Preparación del entorno de laboratorio

Laboratorio 1 Preparación del entorno de laboratorio DEPARTAMENTO DE TECNOLOGÍA ELECTRÓNICA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Laboratorio 1 Preparación del entorno de laboratorio Enunciados de Prácticas de Laboratorio Tecnologías Avanzadas

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

INSTALACIÓN DE UBUNTU SERVER 12.4 EN MÁQUINA VIRTUAL

INSTALACIÓN DE UBUNTU SERVER 12.4 EN MÁQUINA VIRTUAL INSTALACIÓN DE UBUNTU SERVER 12.4 EN MÁQUINA VIRTUAL Grupo de Innovación y Apropiación de Tecnologías de la Información Archivística Compilador: Pedro Antonio Gómez Guarín 1 INSTALACIÓN DE UBUNTU SERVER

Más detalles

Tipos de conexiones de red en software de virtualizacio n: VirtualBox y VMware

Tipos de conexiones de red en software de virtualizacio n: VirtualBox y VMware Tipos de conexiones de red en software de virtualizacio n: VirtualBox y VMware 1. Tipos de conexiones de red Los software de virtualización son programas que se utilizan para crear y manejar máquinas virtuales,

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 Configuración de clientes Laboratorio 2.7 Material utilizado PCs y Routers Linksys CONFIGURACIÓN BÁSICA DE REDES OBJETIVOS

Más detalles

virtual appliance guía de inicio rápido

virtual appliance guía de inicio rápido vybuddy virtual appliance guía de inicio rápido Para VMware Workstation 8 (64-bit) En la guía se usa VMware Workstation 8 (64 bits) para Linux, una VM desarrollada con Ubuntu server 11.10 64-bit y hosts

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

Lab. 1 Configuración de IPv6 y encaminamiento RIPng

Lab. 1 Configuración de IPv6 y encaminamiento RIPng Lab. 1 Configuración de IPv6 y encaminamiento RIPng 1.1. Introducción a IPv6 Una dirección IPv6 está formada por 128 bits. Las direcciones se clasifican en diferentes tipos: unicast, multicast y anycast.

Más detalles

Guía de GNU/Linux para su aplicación en redes Por Paulo Colomés F. www.seguridad-informatica.cl

Guía de GNU/Linux para su aplicación en redes Por Paulo Colomés F. www.seguridad-informatica.cl Guía de GNU/Linux para su aplicación en redes Por Paulo Colomés F. www.seguridad-informatica.cl Guía de GNU/Linux para su aplicación en redes Para comprender de mejor manera esta guía es absolutamente

Más detalles

UD - 4 Funcionamiento de un router. Eduard Lara

UD - 4 Funcionamiento de un router. Eduard Lara UD - 4 Funcionamiento de un router Eduard Lara 1 INDICE 1. Funcionalidades de un router 2. Encaminamiento 3. Tabla de routing 4. Algoritmo de routing 5. Determinación de ruta 6. Protocolos de routing 2

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

Laboratorio 4: Asignación de Direcciones IPv4.

Laboratorio 4: Asignación de Direcciones IPv4. Redes de Datos Laboratorio 4 - Instructivo. Laboratorio 4: Asignación de Direcciones IPv4. Instrucciones generales Para poder realizar exitosamente la práctica, deberá cumplir las siguientes etapas: Previo

Más detalles

Unidad Didáctica Redes 4º ESO

Unidad Didáctica Redes 4º ESO Unidad Didáctica Redes 4º ESO Qué es una red? Una red es la unión de dos o más ordenadores de manera que sean capaces de compartir recursos, ficheros, directorios, discos, programas, impresoras... Para

Más detalles

Configuración básica de la red

Configuración básica de la red Configuración básica de la red Departamento de Sistemas Telemáticos y Computación (GSyC) http://gsyc.urjc.es Febrero de 2012 GSyC - 2012 Configuración básica de la red 1 c 2012 GSyC Algunos derechos reservados.

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

Introducción a TCP/IP

Introducción a TCP/IP Introducción a TCP/IP Este documento es producto de trabajo realizado por Network Startup Resource Center (NSRC at http://www.nsrc.org). Este documento puede ser libremente copiado o re-utilizado con la

Más detalles

Administración de redes IP. Localización y manejo de problemas

Administración de redes IP. Localización y manejo de problemas Administración de redes IP. Localización y manejo de problemas Tabla de Contenidos 6. Administración de redes IP. Localización y manejo de problemas...2 6.1 consideraciones previas y recomendaciones...

Más detalles

Julio Gómez López jgomez@ual.es www.adminso.es Universidad de Almería

Julio Gómez López jgomez@ual.es www.adminso.es Universidad de Almería Cableado Dispositivos de Interconexión Redes inalámbricas CABLEADO Coaxial Par trenzado Fibra óptica Coaxial Coaxial - Desventajas -Seguridad -Velocidad (10 equipos -> 1MB/s, 100 -> 0,1Mb/s Par trenzado!

Más detalles

Práctica 2 - PCs en redes de área local Ethernet

Práctica 2 - PCs en redes de área local Ethernet Práctica 2 - PCs en redes de área local Ethernet 1- Objetivos Para probar las configuraciones de redes empleando routers CISCO necesitaremos PCs que colocaremos en las diferentes redes. Por ello en esta

Más detalles

PXC Proyecto Configuración e instalación de Ultramonkey 25/11/10 Ubuntu 9.04

PXC Proyecto Configuración e instalación de Ultramonkey 25/11/10 Ubuntu 9.04 PXC Proyecto Configuración e instalación de Ultramonkey 25/11/10 Ubuntu 9.04 1. Instalación de Ultramonkey Todos los pasos descritos deben realizarse en todos los servidores (original y réplicas). (a)

Más detalles

virtual appliance guía de inicio rápido

virtual appliance guía de inicio rápido vybuddy virtual appliance guía de inicio rápido Para VMware Workstation 8 (64-bit) En la guía se usa VMware Workstation 8 (64 bits) para Linux, una VM desarrollada con Ubuntu server 12.04 64-bit y hosts

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

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

PXC Proyecto Configuración e instalación de Ultramonkey 25/11/10 Ubuntu 9.04

PXC Proyecto Configuración e instalación de Ultramonkey 25/11/10 Ubuntu 9.04 PXC Proyecto Configuración e instalación de Ultramonkey 25/11/10 Ubuntu 9.04 1. Instalación de Ultramonkey Todos los pasos descritos deben realizarse en todos los servidores (original y réplicas). (a)

Más detalles

Instalar y Configurar VirtualBox

Instalar y Configurar VirtualBox Instalar y Configurar VirtualBox Autor: Samuel Calleros Sánchez Sitio Web: TuxSoluciones.com.mx Copyright Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo

Más detalles

INSTALACIÓN DE UBUNTU SERVER 12.4 EN MÁQUINA VIRTUAL

INSTALACIÓN DE UBUNTU SERVER 12.4 EN MÁQUINA VIRTUAL INSTALACIÓN DE UBUNTU SERVER 12.4 EN MÁQUINA VIRTUAL Grupo de Innovación y Apropiación de Tecnologías de la Información Archivística Compilador: Pedro Antonio Gómez Guarín 1 INSTALACIÓN DE UBUNTU SERVER

Más detalles

Redes en Linux. por Loris Santamaria < loris@lgs.com.ve> 2004-2011 Links Global Services C.A.

Redes en Linux. por Loris Santamaria < loris@lgs.com.ve> 2004-2011 Links Global Services C.A. Redes en Linux por Loris Santamaria < loris@lgs.com.ve> 2004-2011 Links Global Services C.A. Objetivos Los temas que se tratarán en esta Unidad son... Configuración de Interfaces de red Configuración de

Más detalles

Parte III Implementación

Parte III Implementación Parte III Implementación Implementación De qué partimos Buenos conocimientos de sistemas. Sólidos conocimientos de TCP/IP. Teoría de SSOO, redes, y algo de programación. Implementacion: Compartimentación

Más detalles

Práctica de laboratorio: Configuración de direcciones IPv6 en dispositivos de red

Práctica de laboratorio: Configuración de direcciones IPv6 en dispositivos de red Práctica de laboratorio: Configuración de direcciones IPv6 en dispositivos de red Topología Tabla de direccionamiento Dispositivo Interfaz Dirección IPv6 Duración de prefijo Gateway predeterminado Objetivos

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

ANEXO I. Instalación y Configuración de CloudStack.

ANEXO I. Instalación y Configuración de CloudStack. ANEXO I. Instalación y Configuración de CloudStack. La finalidad de este anexo es describir de forma precisa el proceso de instalación y configuración de CloudStack. Éste comienza con la instalación del

Más detalles

Una vez instalada podremos seleccionar los paquetes que deseamos instalar de una lista.

Una vez instalada podremos seleccionar los paquetes que deseamos instalar de una lista. FASE INICIAL. Comenzaremos preparando el entorno que vamos a necesitar para realizar, más tarde, el desarrollo. Las instalaciones las realizaremos en la máquina Linux, el RB ya dispone de las herramientas

Más detalles

Apartado: BrutaliXL Versión: 3 Título: Cortafuegos - Iptables Fecha:

Apartado: BrutaliXL Versión: 3 Título: Cortafuegos - Iptables Fecha: *PRÓPOSITO. En general, un cortafuegos o firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico o un software sobre un sistema operativo.

Más detalles

Guía Comandos para verificar estado de la máquina front-end

Guía Comandos para verificar estado de la máquina front-end Guía Comandos para verificar estado de la máquina front-end Contenido de la guía GUÍA COMANDOS PARA VERIFICAR ESTADO DE LA MÁQUINA FRONT-END... 1 CONTENIDO DE LA GUÍA... 1 INFORMACIÓN ACADÉMICA DE LA GUÍA...

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

PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED

PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED PROYECTO INTEGRADO CLUSTER DE ALTA DISPONIBILIDAD CON HAPROXY Y KEEPALIVED Obra bajo licencia Creative Commons 1 21 de Diciembre de 2012 Índice de contenido Introducción...3 Topología de red...4 Instalación

Más detalles

Práctica 5: Listas de acceso estándar y extendidas

Práctica 5: Listas de acceso estándar y extendidas Práctica 5: Listas de acceso estándar y extendidas Material necesario: - maqueta de routers, cables de red y consola y ordenadores de consola. Introducción: Las listas de acceso (ACLs Access Lists) son

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

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

INTRODUCCION Y ENUNCIADO

INTRODUCCION Y ENUNCIADO INTRODUCCION Y ENUNCIADO Ingeniería de Red La finalidad de ejercicio es que se pueda enrutar tráfico entre las redes 10.0.0.0, 20.0.0.0 y 30.0.0.0 configurando el protocolo de ruteo dinámico OSPF. Conceptos

Más detalles

Práctica de laboratorio: Configuración de HSRP y GLBP Topología

Práctica de laboratorio: Configuración de HSRP y GLBP Topología Topología 2014 Cisco y/o sus filiales. Todos los derechos reservados. Este documento constituye información pública de Cisco. Página 1 de 9 Tabla de asignación de direcciones Dispositivo Interfaz Dirección

Más detalles

REDES DE COMPUTADORES Laboratorio

REDES DE COMPUTADORES Laboratorio 1nsloo.cl REDES DE COMPUTADORES Laboratorio Práctica 3: Protocolos de enrutamiento dinámico RIP y OSPF 1. OBJETIVO El objetivo de esta práctica es conocer el modo de operar de los protocolos de enrutamiento

Más detalles

UNIVERSIDAD CENTRAL Facultad de Ingeniería Planificación y Gestión de Redes. Práctica de laboratorio No. 5. Práctica OSPF

UNIVERSIDAD CENTRAL Facultad de Ingeniería Planificación y Gestión de Redes. Práctica de laboratorio No. 5. Práctica OSPF UNIVERSIDAD CENTRAL Facultad de Ingeniería Planificación y Gestión de Redes Práctica de laboratorio No. 5 Práctica OSPF Nota Importante: Esta práctica está diseñada originalmente para ser realizada en

Más detalles

... Internetworking Protocol (IP)

... Internetworking Protocol (IP) Tema 2: Internetworking Protocol () 1 Tema 2: Internetworking Protocol () 2 Internetworking Protocol () Tema 2: Internetworking Protocol () Problema a resolver: Cómo conseguir que las aplicaciones sean

Más detalles

Figura 1. Red de ejemplo para DHCP Server

Figura 1. Red de ejemplo para DHCP Server Un servidor DHCP asigna dinámicamente direcciones IP a las PC dentro de una red, esto evita que tengamos que configurar la dirección IP de cada máquina por separado por lo que es muy utilizado en todo

Más detalles

Ismael Briones Vilar ARP SPOOFING Espiando en redes segmentadas

Ismael Briones Vilar ARP SPOOFING Espiando en redes segmentadas Ismael Briones Vilar ARP SPOOFING Espiando en redes segmentadas La segmentación de redes mediante el uso de Switches parecía la solución perfecta para evitar los temibles sniffers. Pero no es oro todo

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

Sistemas de Transporte de Datos (9186). Curso 2010-11 Ingeniería Informática

Sistemas de Transporte de Datos (9186). Curso 2010-11 Ingeniería Informática Sistemas de Transporte de Datos (9186). Curso 2010-11 Ingeniería Informática Carlos A. Jara Bravo (cajb@dfists.ua.es) Grupo de Innovación Educativa en Automática 2010 GITE IEA Sistemas de Transporte de

Más detalles

Redes de Computadores

Redes de Computadores Internet Protocol (IP) http://elqui.dcsc.utfsm.cl 1 La capa 3 más usada en el mundo.. http://elqui.dcsc.utfsm.cl 2 Crecimiento de Internet http://elqui.dcsc.utfsm.cl 3 Crecimiento de Internet http://elqui.dcsc.utfsm.cl

Más detalles

Práctica de laboratorio 11.6.1: Práctica de laboratorio sobre configuración básica de OSPF

Práctica de laboratorio 11.6.1: Práctica de laboratorio sobre configuración básica de OSPF Práctica de laboratorio 11.6.1: Práctica de laboratorio sobre configuración básica de Objetivos de aprendizaje Al completar esta práctica de laboratorio, usted podrá: Conectar una red de acuerdo con el

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

- ERouting Final Exam - CCNA Exploration: Routing Protocols and Concepts (Versión 4.0)

- ERouting Final Exam - CCNA Exploration: Routing Protocols and Concepts (Versión 4.0) 1 of 20 - ERouting Final Exam - CCNA Exploration: Routing Protocols and Concepts (Versión 4.0) 1 Cuáles son las afirmaciones verdaderas con respecto al encapsulamiento y desencapsulamiento de paquetes

Más detalles

Uso del comando traceroute en sistemas operativos

Uso del comando traceroute en sistemas operativos Uso del comando traceroute en sistemas operativos Contenido Introducción prerrequisitos Requisitos Componentes Utilizados Convenciones Funcionamiento general Cisco IOS y Linux Microsoft Windows Limitación

Más detalles

Gestión de Recursos y Seguridad en Redes Seguridad en la red con Open Source. Derman Zepeda Vega. dzepeda@unan.edu.ni

Gestión de Recursos y Seguridad en Redes Seguridad en la red con Open Source. Derman Zepeda Vega. dzepeda@unan.edu.ni Gestión de Recursos y Seguridad en Redes Seguridad en la red con Open Source Derman Zepeda Vega dzepeda@unan.edu.ni 1 Agenda Introducción a los Firewall Iptables en Linux Elaboración de un firewall básico

Más detalles

IP Aliasing en 1 minuto

IP Aliasing en 1 minuto IP Aliasing en 1 minuto Javier Quintano Documento Personal javier@jaxvinet.homelinux.org versión 0.1 12 de noviembre de 2004 IP Aliasing es la técnica que usamos para asignar a una interface física de

Más detalles

HOW TO SOBRE FIREWALL

HOW TO SOBRE FIREWALL HOW TO SOBRE FIREWALL 1- En este how to estaremos estableciendo algunas reglas con el firewall para bloquear el acceso, o permitirlo. Lo primero que haremos es abrir la consola, ubicada en aplicaciones,

Más detalles

Carlos M. Martínez LACNIC carlos @ lacnic.net. 20-2222 de Junio de 2011 Tegucigalpa, Honduras

Carlos M. Martínez LACNIC carlos @ lacnic.net. 20-2222 de Junio de 2011 Tegucigalpa, Honduras Lab BGP en IPv6 Simulación de un punto de intercambio de tráfico (IXP) Carlos M. Martínez LACNIC carlos @ lacnic.net 20-2222 de Junio de 2011 Tegucigalpa, Honduras IXPs: Puntos de intercambio de tráfico

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

Capítulo 7: Implementando Servicios de direccionamiento IP

Capítulo 7: Implementando Servicios de direccionamiento IP CCNA Exploration 4 Acceso a la WAN Capítulo 7: Implementando Servicios de direccionamiento IP Ricardo José Chois Antequera INSTITUTO TECNOLÓGICO DE SOLEDAD ATLÁNTICO - ITSA Version 4.0 2006 Cisco Systems,

Más detalles

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Facultad de Ingeniería Redes de Datos Práctica 6 Capa2 Modelo OSI

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Facultad de Ingeniería Redes de Datos Práctica 6 Capa2 Modelo OSI PRÁCTICA 6 Instalación de una Red Básica en Plataforma LINUX 1.- Objetivo de Aprendizaje: El alumno: Al finalizar la práctica tendrá la capacidad de configurar una tarjeta de red. Será capaz de instalar

Más detalles

Lab 10: Configuración Básica de un Router

Lab 10: Configuración Básica de un Router Departamento Académico de Informática Ingº Manuel Peñaloza Figueroa Dime y lo olvidaré. Muéstrame y lo recordaré. Involúcrame y lo entenderé Proverbio chino 1. OBJETIVOS: 1.1. Desarrollar las habilidades

Más detalles

Laboratorio 1 Preparación del entorno de laboratorio

Laboratorio 1 Preparación del entorno de laboratorio DEPARTAMENTO DE TECNOLOGÍA ELECTRÓNICA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Laboratorio 1 Preparación del entorno de laboratorio Enunciados de Prácticas de Laboratorio Tecnologías Avanzadas

Más detalles

Administración de la red

Administración de la red Diseño y Administración de Sistemas y Redes http://gsyc.es Curso 2007 2008 Configuración básica de la red 1 Configuración básica de la red Interfaz de red El Hardware de red puede ser muy variable, pero

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

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

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

MANUAL DE CONFIGURACIÓN

MANUAL DE CONFIGURACIÓN MANUAL DE CONFIGURACIÓN DrayTek Vigor 3100 Series Ingeniería de Clientes 15/04/2011 1 ÍNDICE 1. Cargar plantilla / Guardar plantilla... 3 2. Acceso Vigor... 4 3. Cambiar usuario PPP... 5 4. Cambiar password

Más detalles

Práctica 6: Configuración de TCP/IP en Windows XP y Linux 1. Introducción

Práctica 6: Configuración de TCP/IP en Windows XP y Linux 1. Introducción Práctica 6: Configuración de TCP/IP en Windows XP y Linux 1. Introducción Esta práctica está dedicada a revisar el procedimiento básico de instalación y configuración de los protocolos TCP/IP en Windows

Más detalles

Descripción del software IMUNES para su utilización en el Laboratorio de Redes y Sistemas Operativos.

Descripción del software IMUNES para su utilización en el Laboratorio de Redes y Sistemas Operativos. Descripción del sotfware IMUNES 1 Descripción del software IMUNES para su utilización en el Laboratorio de Redes y Sistemas Operativos. Gabriel Astudillo Muñoz Departamento de Electrónica, Universidad

Más detalles

Práctica de laboratorio 4.2.5a Pruebas de conectividad Ping

Práctica de laboratorio 4.2.5a Pruebas de conectividad Ping Práctica de laboratorio 4.2.5a Pruebas de conectividad Ping Objetivo Usar el comando ping para enviar datagramas ICMP al host objetivo. Verificar que la capa de red entre el origen y el destino funcione

Más detalles

Enrutamiento y filtrado

Enrutamiento y filtrado Asegurando tu red con Iptables Proxy NAT IDS: PARTE 1 http://blog.desdelinux.net/iptables-asegurando-red-parte1 Este post intenta esclarecer un poco de como funcionan las redes y como convertir nuestro

Más detalles

Práctica 4: Configuración básica de conmutadores Ethernet Cisco

Práctica 4: Configuración básica de conmutadores Ethernet Cisco Práctica 4: Configuración básica de conmutadores Ethernet Cisco 1- Objetivos En esta práctica se aprenderá cómo obtener información sobre la configuración y funcionamiento de un conmutador Ethernet con

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

Lab BGP en IPv6 Simulación de un punto de intercambio de tráfico (IXP)

Lab BGP en IPv6 Simulación de un punto de intercambio de tráfico (IXP) Lab BGP en IPv6 Simulación de un punto de intercambio de tráfico (IXP) Workshop IPv6 8-10 de agosto 2011 San:ago de Chile Carlos Mar?nez (carlos @ lacnic.net) IXPs: Puntos de intercambio de tráfico Un

Más detalles