Estas notas son para mi uso personal, pueden no estar actualizadas, tener errores, no ser claras etc... por lo que no pretendo que sean de utilidad, de cualquier forma, si te son de utilidad, mándame una postal. :-) Gracias por entender ! oscar@medina-web.com La mascara de subred (netmask) para decidir si dos maquinas están en la misma red usando los siguientes pasos. 1.- De el IP fuente con el netmask, toma la parte de la red 2.- De el IP destino con el netmask, toma la parte de la red 3.- Si los dos resultados son idénticos, las dos maquinas se encuentran en la misma red. Las computadoras en la misma red se pueden comunicar directamente, para comunicarse con una maquina en otra red se requiere un ruteador. Ruteo Que es un ruteador ? Un ruteador es un dispositivo especializado que contiene una tabla de direcciones y la forma de llegar a ellas, adicionalmente un ruteador puede tener conocimiento de otros ruteadores. Normalmente, una red pequeña solo tiene un ruteador y puesto que ese ruteador es la única forma de salir de esa red se le puede definir como gateway. Es posible tener mas de un ruteador en una red cumpliendo funciones de enlace especificas (por ejemplo, un ruteador para Internet y otro para alcanzar maquinas dentro de la empresa pero que se encuentran en otra red) Cuando se hace la configuración TCP/IP de un cliente o de un servidor, se tiene la opción de especificar un default gateway. Este es el ruteador usado cuando no se tiene la ruta hacia el IP de destino. El trabajo de ese ruteador es ya sea de conocer la ruta hacia el destino o de enviar el paquete a otro ruteador que pueda conocer la ruta. Este otro ruteador se convierte en el default gateway de el ruteador inicial. Esta es la forma en que todo Internet funciona (mas o menos). Lo anterior se define siguiendo estos pasos: - Si el destino se encuentra en la misma red, envía el paquete directamente - Si el destino no se encuentra en la misma red y se conoce la ruta (mediante la tabla de ruteo local), envía el paquete por medio de esa ruta. - Si no se tiene información de la ruta, se envía el paquete a el default gateway RIP (Routing Information Protocol) El protocolo RIP usado con IP es el mismo que se usa con IPX, y es derivado del mismo código fuente de XNS (Xerox Network System). Aunque RIP no fue incluido originalmente en la suite de TCP/IP, fue incluido en la versión gratuita de Unix distribuida por la Universidad de Berkeley, y desde entonces se ha convertido en el protocolo mas popular para ruteo en redes TCP/IP. Un ruteador RIP periódicamente envía a través de el broadcast address un mensaje de ruteo que contiene una entrada para cada red que el puede alcanzar y el costo (numero de hops o saltos) de esa red. Cada entrada en un ruteo recibido por un ruteador RIP es adicionada a la tabla de ruteo local. El ruteador que envía el mensaje de ruteo es recordado como el siguiente ruteador o salto (hop) en la ruta hacia la red en la entrada. Si llegara la misma ruta de dos servidores diferentes, el ruteador descarta la que tenga mas costo (mayor salto de hops) y mantiene la mas corta. RIP permite un costo máximo de 15 hops. Una vez que la ruta se encuentra en la tabla de ruteo, tiene que ser validada constantemente, normalmente los ruteadores RIP envían las rutas conocidas cada 30 segundos. Cada vez que una ruta es actualizada, se comienza a contar el intervalo de tiempo para su nueva actualización, si el refresh no es posible en 180 segundos, se asume que la ruta ya no es valida y se descarta de la tabla de ruteo. RIPII es una mejora a el protocolo RIP que permite incluir mascaras de subred (sub net mask) dentro de la información de la ruta. Cuando RIP es usado en una subred, todas las subredes deben de tener el mismo netmask (de lo contrario el broadcast address no será el mismo para todas las maquinas) RIPII puede ser usado en topologías de red que requieran mascaras de red de longitud variable y puede soportar el subnet de cero. RIPII también puede verificar el intercambio de mensajes de ruteo. RIPII puede usar una red especial llamada multicast el lugar de broadcast address. No todos los ruteadores RIP soportan RIPII, pero todos los ruteadores RIPII soportan RIP. Puesto que RIP no puede detectar o corregir ruteos erróneos tales como loops, las rutas que se obtengan y excedan de 15 hops son invalidas. Esto significa que la fuente y el destino de la ruta no puede estar separado por mas de 15 ruteadores (15 hops o saltos). Problemas comunes de ruteo con RIP Los ruteadores RIP pueden también experimentar inconsistencias en sus tablas de ruteo. Esto es debido a el tiempo que toma la sincronización para todos los ruteadores RIP de la red. El problema mas común con RIP es conocido como el problema de conteo infinito, el cual esta descrito a continuación: ### ## D R3 R2 ### # D R3 R2 # En el dibujo anterior las flechas muestran la ruta a el destino D. El ruteador R2 ha almacenado que para llegar a el destino D, tiene que pasar por el ruteador R3. Si la liga de R3 hacia D se cae, R3 removerá a el destino D de su tabla de ruteo (puesto que ya no puede verlo). Pero como para R2 el tiempo de actualización no ha llegado, R2 aun tiene en su tabla de ruteo que para llegar a el destino D tiene que pasar por el ruteador R3. R2 enviara una actualización a R3 diciendo que el (R2) puede llegar a el destino D con un costo de 2 hops (R3 lo acepta puesto que ya no tiene esa ruta en su tabla de ruteo). R3 calcula que puede alcanzar a el destino D en 3 hops, un hop para alcanzar a R2 y dos mas para alcanzar a D. Entonces R3 asigna una nueva ruta para el destino D en su tabla de ruteo. Este proceso genera un loop de ruteo. En el ejemplo anterior, cualquier paquete de datos que tratara de llegar a el destino D recibido por R2 o R3 es enviado atrás y adelante hasta que el tiempo de vida de el paquete expire. Puesto que R3 y R2 continúan actualizándose uno a otro, el proceso de actualización toma cierto tiempo para resolverse. Puesto que R2 no actualiza la ruta hacia el destino D con el costo de 1 (solo 1 hop pasando por R3), su ruta hacia el destino D con el costo de 2 eventualmente expira. Entonces R2 se actualiza con la información de R3 y toma la ruta hacia D con el costo de 3 y calcula nuevamente el costo llegando a 4. En la siguiente actualización, R3 incrementa el costo a 5. Ambos ruteadores continúan incrementando su costo (numero de hops) hasta que llegue a 16. Cuando el costo para llegar a D es mayor a 15 la ruta hacia D es finalmente desechada de ambas tablas de ruteo. Como se puede imaginar este proceso puede tardar varios minutos. RIPII soporta la característica de split horizon que es un mecanismo mediante el cual las rutas no son propagadas a la interface desde donde vienen, lo cual significa que en el ejemplo anterior R3 envía la ruta a R2, pero R2 no puede enviar la misma ruta a R3. R3 no continua actualizando la ruta hacia D puesto que D esta caído y la ruta en R2 se elimina puesto que no hay actualización. Aunque split horizon no llega a cubrir el problema de manera completa si dentro de el escenario se encuentran 3 routers, por ejemplo: # # ## R1 #### D R3 R2 R3 esta a un hop de distancia de D y los ruteadores R1 y R2 están a dos hops de distancia de D. Si la conexión hacia D se cae, R3 deja de enviar actualización acerca de la ruta hacia R1 y R2. La regla de split horizon no permite a R1 y R2 propagar la ruta de nuevo hacia R3 (puesto que de ahí la obtuvieron). Como resultado de esto R1 y R2 suponen que el destino D esta levantado todavía R1 y R2 ya no reciben la actualización de la ruta hacia D, así que la ruta hacia D en ambos servidores se descarta por timeout de actualización. Pero supongamos que la ruta se descarta en R1 antes de que lo haga en R2, lo cual implicaría que R2 tendría la ruta pero R1 no (puesto que ya se descarto por timeout), si R2 propaga la ruta a R1, R1 la tomaría y concluiría que esta a tres hops del destino D (basándose en que R2 esta a dos hops del destino D). Entonces R1 informaría a R3 que esta a tres hops del destino D. R3 asumiría que esta a cuatro hops del destino D y que D es accesible pasando por R1. La ruta eventualmente genera un timeout en R2 (puesto que no hay refresh de la ruta). Después de esto R3 informa a R2 que esta a cuatro hops de el destino D, R2 adiciona la ruta y concluye que esta a 5 hops del destino D, el loop continua. Cuando la red crece, el ruteo se convierte en un punto de atención. RIP tiene dos defectos primordiales: Puesto que solo soporta 15 hops máximo, no es posible implementar RIP en una red con mas de 15 ruteadores. Cada ruteador RIP hace un broadcast de las rutas que conoce hacia la red de manera continua, lo cual genera trafico en la red. Dependiendo de el esquema de ruteo se pueden generar loops de direccionamiento (tal como se explico) . Una alternativa a RIP es OSPF (Open Shortest Path First), que trabaja mejor en redes complejas. En lugar de enviar por broadcast todas las redes que conoce, solo envía información acerca que las redes que están conectadas a el ruteador OSPF, y solo lo hace cuando la información cambia. Esto minimiza el monto de trafico en la red usado por el ruteador para actualización de tablas de ruteo. Rutas dinámicas y estáticas Para que TCP/IP pueda rutear, debe tener información acerca de las rutas disponibles. Tal información es mantenida normalmente en una tabla de ruteo, donde cada entrada en esa tabla consiste de: Dirección del destino final Dirección del siguiente ruteador en destino final El costo de alcanzar el destino final (distancia o numero de hops) Las entradas a la tabla de ruteo pueden ser dinámicas o estáticas. Las entradas dinámicas son actualizadas mediante el protocolo de ruteo (en caso de SCO, RIP). Las entradas manuales (mediante comandos de ruteo en el sistema operativo) son conocidas como rutas estáticas, ambos esquemas tienen las siguientes: Ventajas. El ruteo dinámico permite tener conocimiento automático y sin intervención humana de las rutas de la red El ruteo estático permite ahorrar ancho de banda puesto que el ruteo dinámico utiliza un esquema de broadcast y esto en algunos casos puede saturar los canales de comunicaciones. Desventajas. El ruteo dinámico puede cargar el ancho de comunicaciones de manera significativa. El ruteo dinámico implica un proceso adicional en el servidor Unix. El ruteo estático no toma en cuenta las actualizaciones de la red, adicionalmente se tiene que tener control de todas las rutas de la red. Ruteo en SCO. Estándares. Las versiones de SCO 3.2.4.2 y posteriores implementan el protocolo de ruteo RIP. A partir de la versión 5.0 en adelante se implementa RIPII (permitiendo el uso de mutlicast) Procesos involucrados en el ruteo. El proceso involucrado en el ruteo dinámico a través de RIP o RIPII es routed, este proceso es iniciado al levantar TCP/IP de forma automática. El comando de Unix para desplegar la tabla de ruteo existente es: netstat -nr Como definir rutas estáticas. Usando el comando: route add por ejemplo, para adicionar el servidor 200.4.48.10 que esta a través de el ruteador 206.48.244.97 seria: route add 200.4.48.10 206.48.244.97 También se pueden generar rutas estáticas para toda una red, como por ejemplo: Las maquinas de la red 200.4.48.* (todas las de la red 200.4.48) se encuentran a través del ruteador 206.48.244.97 route add -net 200.4.48.0 206.48.244.97 Adicionalmente se pueden definir rutas estáticas o manuales para el ruteador por default o default gateway usando route add default por ejemplo: route add default 206.48.244.97 1 El numero de hops indica el numero de saltos que se tienen que hacer para llegar a este destino, un numero de hops 0 indica que el gateway es local (es decir una tarjeta local) En version 5.0 en adelante el numero de hops es opcional. Es importante hacer notar que el gateway a el que se hace referencia tiene que estar en la misma red que el servidor, (servidor 206.48.244.96, ruteador 206.48.244.97) de otra manera el comando routed enviara el siguiente error: Network is unreachable Si se desea remplazar totalmente el esquema de ruteo dinámico y únicamente implementar ruteo estático, se tiene que comentar el procedimiento que levanta a el proceso de routed en el archivo /etc/tcp (que de hecho es una liga hacia /etc/rc2.d/S85tcp) y generar una archivo en /etc/rc2.d que contenga todas las rutas. (eg. /etc/rc2.d/S99rutas) Como saber por donde pasa un paquete ? Se puede utilizar el comando traceroute para trazar la ruta que un paquete recorre hasta llegar a su destino final (o en caso erróneo hasta el ultimo ruteador alcanzado) La sintaxis de ®traceroute” es : traceroute Windows 3.11 en adelante (con TCP/IP instalado) implementa este esquema mediante el comando tracert que se encuentra normalmente en el directorio \windows Como definir un servidor como Gateway Muchas veces es necesario tener un servidor que actúe como un gateway entre la red de backbone y las subredes existentes en la institución. B a c k b o n e ######### hacia el backbone hacia el backbone a la red local a la red local En este caso es necesario instalar dos tarjetas de red a el servidor Unix y declarar un IP para cada una de ellas. (aunque dependiendo de la necesidad se puede generar un alias de la tarjeta y usar una sola tarjeta, aunque por falta de tiempo en esta sesión les pediría que me contactaran después los que estuvieran interesados en esta característica) Un punto importante si se desea que los paquetes puedan viajar de una tarjeta a otra es indicarle a la configuración de TCP/IP que este servidor actuara como un gateway para otras redes. (esto significa que pueda pasar los paquetes de una interfase de red a la otra) Esto se puede completar en versión 3.0 de la siguiente manera: Cuando se da de alta una segunda tarjeta de red usando netconfig el sistema pregunta si se activa la característica de gateway en este caso contestar afirmativamente incluyendo los parámetros ipsendredirects y ipforwarding con el valor de 1 en el archivo /etc/conf/cf.d/stune y religar el kernel. En versión 5.0: Dentro de la configuración de la tarjeta de red con netconfig seleccionar el submenu advanced y seleccionar yes donde dice Gateway. desde el prompt del sistema operativo: # inconfig ipsendredirects 1 # inconfig ipforwarding 1 y rebootear el equipo. Como diagnosticar problemas comunes de ruteo. Use traceroute desde la fuente y el destino y verifique que la ruta de salida sea la misma de llegada (solo que al revés). En el peor de los casos traceroute indicara hasta donde llega el paquete (es decir hasta que ruteador llega). Verifique que los equipos tengan el netmask correcto (puesto que en algunas implementaciones de RIP la propagación de rutas se hace a través de el broadcast address y un netmask erróneo no generara el mismo broadcast address de la red). Verifique que están definidos como gateway correctamente los equipos Muchas veces el demonio de routed acepta rutas invalidas o erróneas de otros equipos, es conveniente deshabitar el proceso de routed de los archivos de arranque de TCP/IP (tal y como se comento anteriormente) y comparar las tablas de ruteo sin routed contra las tablas de ruteo con routed (usando netstat -nr). En este caso es también conveniente verificar la bitácora del sistema para identificar el equipo que esta enviando las rutas erróneas (verifique /usr/adm/syslog, ahí aparecerán las referencias del demonio routed de la siguiente manera: routed [234] : rt_delete 805c2b00, ifp = net0 routed [234] : inaddr = ce30f028, mask = ffffff00 En el primer caso indica que el demonio de routed esta eliminando de la tabla de ruteo la dirección 128.92.43.0 (80.5c.2b.00 en hexadecimal) que estaba saliendo por la interfase de red net0 (use ifconfig -a para saber a que dirección local pertenece la interface net0). En el segundo caso indica que el demonio de routed adiciono una ruta que proviene de la dirección 206.48.240.40 y que el netmask es: 255.255.255.0 Lecturas sugeridas SCO Help Networking Guide. Dos-Unix Networking and Internetworking, Michael J. Burgard, Kenneth D. Phillips, Edit. Wiley Professional Computing. Internetworking With TCP/IP : Principles, Protocols, and Architecture, Douglas E. Comer Edit. Prentice Hall. Unix Internetworking, Uday O. Pabrai, Edit. Artech House