Juan Segovia, Junio 2012 jsegovia@eia.udg.edu 1. 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... 1 2. Diseño de la red... 2 3. Configuración de Linux... 3 3.1. Paquetes de software de Linux...3 3.2. Configuraciones básicas de red en Linux...3 3.3. Configuración de NAT en ospf1...5 3.4. Configuración de sysctl...5 4. Implementación virtualizada de la red...6 4.1. Enrutadores...6 4.2. Switches... 7 Switches usando brctl...7 Switches usando VDE...8 El dispositivo veth...9 5. Configuración de Quagga... 9 5.1. Acceso a la consola de Quagga...9 5.2. Contenido de los archivos de configuración...9 5.3. Anuncio de la ruta por defecto al exterior...10 6. Puesta a punto y verificación de funcionamiento...10 6.1. Configuración de NAT en el servidor real...11 Página 1/28
6.2. Pruebas básicas de las tablas de rutas y de conectividad...11 6.3. Cuidado con lo que traceroute nos cuenta...12 6.4. 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...15 7. Observaciones sobre rp_filter... 15 8. KVM y redes virtualizadas: algunas lecciones...17 9. Anexo de archivos de configuración y scripts...18 9.1. Configuración de Linux...18 9.2. Quagga... 19 9.3. Scripts... 20 10. Recursos... 27 2. 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
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 0.99.21-2. El sistema operativo es Ubuntu Linux 12.04 LTS (x86, 32 bits), con kernel 3.2.0. 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 10.1.0.0/24, mientras que la red de conexión al gateway externo es 192.168.122.0/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 10.100.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 10.100.NN.0/24 vía OSPF para facilitar la inspección del correcto funcionamiento del enrutamiento cuando hay cambios en la topología. 3.1. 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
gw 192.168.122.1 10.100.23.0/24 192.168.122.10 1 10.1.1.2 10.1.1.3 2 10.1.2.3 10.100.52.0/24 10.1.5.2 10.1.5.3 10.1.2.2 10.100.53.0/24 5 10.1.4.2 10.1.4.3 4 10.1.3.3 10.1.3.2 3 10.100.43.0/24 10.100.32.0/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 192.168.122.10 netmask 255.255.255.0 gateway 192.168.122.1 dns-nameservers 84.88.128.2 84.88.128.3 /etc/hosts # ospf2, ospf3, o lo que corresponda. 127.0.0.1 localhost ospf2 Además, si cada ospf# se crea a partir de una copia única, conviene ajustar el hostname: Página 4/28
/etc/hostname ospf2 En los demás enrutadores (ospf2 al osp5) conviene tener lo siguiente: /etc/resolv.conf nameserver 84.88.128.2 nameserver 84.88.128.3 3.3. 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 10.1.0.0/16 -A POSTROUTING -s 10.1.0.0/16! -d 10.1.0.0/16 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 10.1.0.0/16! -d 10.1.0.0/16 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 10.1.0.0/16! -d 10.1.0.0/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
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: http://www.kernel.org/doc/documentation/networking/ip-sysctl.txt 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 11.04 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. 4.1. 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
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. 4.2. 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
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
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. 5.1. 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 127.0.0.1/8 ip address 10.1.3.2/32 interface eth0 ip address 10.1.2.2/24 link-detect Página 9/28
interface eth1 ip address 10.1.3.2/24 link-detect ip route 10.100.32.0/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 10.1.3.2/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 10.1.3.2/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 (10.100.32.0/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 10.1.2.0/24 area 0.0.0.0 network 10.1.3.0/24 area 0.0.0.0 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
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 1 2 3 4 5; 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:84.88.154.173 Bcast:84.88.155.255 Mask:255.255.254.0 lo tap0 virbr0 Link encap:local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 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:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 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). 6.1. 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 192.168.0.x -A POSTROUTING -s 192.168.122.0/24! -d 192.168.122.0/24 -p tcp -j MASQUERADE to-ports \ 1024-65535 -A POSTROUTING -s 192.168.122.0/24! -d 192.168.122.0/24 -p udp -j MASQUERADE to-ports \ 1024-65535 -A POSTROUTING -s 192.168.122.0/24! -d 192.168.122.0/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
Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.1.4.2 0.0.0.0 UG 0 0 0 eth1 10.1.1.0 10.1.3.2 255.255.255.0 UG 0 0 0 eth0 10.1.2.0 10.1.3.2 255.255.255.0 UG 0 0 0 eth0 10.1.2.3 10.1.3.2 255.255.255.255 UGH 0 0 0 eth0 10.1.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.1.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.1.5.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.1.5.2 10.1.4.2 255.255.255.255 UGH 0 0 0 eth1 10.1.5.3 10.1.4.2 255.255.255.255 UGH 0 0 0 eth1 10.100.23.0 10.1.3.2 255.255.255.0 UG 0 0 0 eth0 10.100.32.0 10.1.3.2 255.255.255.0 UG 0 0 0 eth0 10.100.43.0 0.0.0.0 255.255.255.0 U 0 0 0 * 10.100.52.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.100.53.0 10.1.4.2 255.255.255.0 UG 0 0 0 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 10.1.3.2 1 Full/DR 34.668s 10.1.3.2 eth0:10.1.3.3 10.1.5.3 1 Full/Backup 33.319s 10.1.4.2 eth1:10.1.4.3 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). 6.3. 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 10.1.1.2 traceroute to 10.1.1.2 (10.1.1.2), 30 hops max, 60 byte packets 1 10.1.4.2 0.852 ms 0.745 ms 0.727 ms 2 10.1.1.2 2.460 ms 2.447 ms 2.346 ms ospf4$ traceroute -n 10.1.1.3 traceroute to 10.1.1.3 (10.1.1.3), 30 hops max, 60 byte packets 1 10.1.4.2 1.047 ms 0.977 ms 0.959 ms 2 10.1.1.2 2.167 ms 2.245 ms 3.085 ms 3 10.1.1.3 2.684 ms 2.986 ms 2.675 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 10.1.1.3 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
http://www.linuxmisc.com/4-linux/e1374e0766b9ba4d.htm Si en vez de traceroute usamos tracepath (paquete iputils-tracepath), veremos otro resultado: ospf4$ tracepath -n 10.1.1.3 1: 10.1.3.3 0.104ms pmtu 1500 1: 10.1.3.2 0.675ms 1: 10.1.3.2 1.590ms 2: 10.1.1.3 1.423ms 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 10.1.1.3 y 10.1.2.3 mientras se abre una sesión SSH a 10.1.1.3, 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). 6.4. 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 10.1.3.3 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
Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.1.4.2 0.0.0.0 UG 0 0 0 eth1 10.1.1.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.1.2.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.1.2.3 10.1.4.2 255.255.255.255 UGH 0 0 0 eth1 10.1.3.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.1.3.2 10.1.4.2 255.255.255.255 UGH 0 0 0 eth1 10.1.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.1.5.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.1.5.2 10.1.4.2 255.255.255.255 UGH 0 0 0 eth1 10.1.5.3 10.1.4.2 255.255.255.255 UGH 0 0 0 eth1 10.100.23.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.100.32.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.100.43.0 0.0.0.0 255.255.255.0 U 0 0 0 * 10.100.52.0 10.1.4.2 255.255.255.0 UG 0 0 0 eth1 10.100.53.0 10.1.4.2 255.255.255.0 UG 0 0 0 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 10.1.2.2 1: 10.1.4.3 0.155ms pmtu 1500 1: 10.1.4.2 1.041ms 1: 10.1.4.2 1.046ms 2: 10.1.5.2 2.234ms 3: 10.1.1.3 2.973ms 4: 10.1.2.2 3.918ms reached Resume: pmtu 1500 hops 4 back 61 Igualmente, un tracepath a 10.1.3.2 seguiría el mismo camino. RUTAS DIRECTAS A TODAS LAS INTERFACES DE LOS ENRUTADORES Supongamos ahora que la interfaz que corresponde a 10.1.2.2 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 10.1.2.2, no hay respuesta. Esta asimetría se da por el hecho de que, desde la perspectiva de ospf2, la red 10.1.2.0/24 sigue up, y además el número 10.1.2.2, 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
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
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 10.1.3.2, basta con depositar el tráfico en la interfaz de salida eth0 (10.1.3.3). Si esta interfaz falla, ya vimos que el tráfico pega la vuelta, por lo que siguiente salto hacia 10.1.3.2 será ospf5 (10.1.4.2). Supongamos ahora que el enlace se recupera. Inmediatamente, ospf4 empezará a recibir los mensajes enviados a las direcciones de broadcast (224.0.0.5) por osp3. Por lo tanto, osp4 sabe que existe ospf3 y que su IP es 10.1.3.2 (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 10.1.3.2/24, Broadcast 10.1.3.255, Area 0.0.0.0... 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 10.1.3.0/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 1 10.1.1.2 10.1.1.3 2 10.1.2.3 10.1.5.2 5 10.1.5.3 10.1.4.2 10.1.4.3 Fig. 4. Visión simplificada de la topología para analizar por qué se debe desactivar el strict Reverse Path Forwarding 4 10.1.3.3 10.1.3.2 10.1.2.2 3 Página 16/28
10.1.5.3 1 Full/DR 34.089s 10.1.4.2 eth1:10.1.4.3 10.1.3.2 1 Init/DROther 33.075s 10.1.3.2 eth0:10.1.3.3 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 http://people.gnome.org/~markmc/qemu-networking.html). 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
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. 9.1. 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 192.168.122.10 # netmask 255.255.255.0 # gateway 192.168.122.1 # dns-nameservers 84.88.128.2 84.88.128.3 # /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 84.88.128.2 Página 18/28
nameserver 84.88.128.3 # /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 10.1.0.0/16 -A POSTROUTING -s 10.1.0.0/16! -d 10.1.0.0/16 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 10.1.0.0/16! -d 10.1.0.0/16 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 10.1.0.0/16! -d 10.1.0.0/16 -j MASQUERADE COMMIT 9.2. Quagga! /etc/quagga/zebra.conf hostname ospf3 password algunatexto enable password otrotexto interface lo ip address 127.0.0.1/8 ip address 10.1.3.2/32 interface eth0 ip address 10.1.2.2/24 link-detect interface eth1 ip address 10.1.3.2/24 link-detect ip route 10.100.32.0/24 null0! /etc/quagga/ospf3.conf hostname ospf3 password zebra router ospf network 10.1.2.0/24 area 0.0.0.0 network 10.1.3.0/24 area 0.0.0.0 redistribute static! -- Página 19/28
! para ospf1, se debe agregar:! default-information originate! -- 9.3. Scripts./bin/config # (c) 2012 Juan Segovia S. # jsegovia@eia.udg.edu # 2012-05-30 # # 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="10.1.5.1 netmask 255.255.255.0 broadcast 10.1.5.255" ;; 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