Entregable 3.1

Entregable 3.1

de Bruno Stefano Lombardo Palleiro -
Número de respuestas: 19

Hola, buenas tardes! 

Con mi grupo estamos teniendo el problema que no nos anda el traceroute desde  server21 a internet porque creemos que confunde las subredes que tienen el mismo prefijo 192.168.0.0/30. 

Sabemos que esto no debería suceder porque son redes distintas, estuvimos revisando las tablas y parecían estar correctas. Puede tener algo que ver con la configuración del quagga?

Saludos


En respuesta a Bruno Stefano Lombardo Palleiro

Re: Entregable 3.1

de Federico Rodriguez -

Bruno, necesitaría más información, dado que no está en el mensaje. Paso a detallar:

- El ISP está utilizando RIP?

- A donde se dirige el traceroute cuando lo ejecutan?

Igualmente aprovecho para realizar algunas aclaraciones, la red 192.168.0.0/30 tiene solamente dos IPs utilizables, 192.168.0.1 y 192.168.0.2, por lo que el enlace a la institución y hacia internet utiliza el mismo par de IP's. Está red no debería ser publicada por RIP, dado que son dos redes distintas que tienen la misma numeración.

Sin tener toda la información creo que vuestro problema está ahí.

Quedo a las órdenes por respuestas y más aclaraciones.

Federico

En respuesta a Federico Rodriguez

Re: Entregable 3.1

de Bruno Stefano Lombardo Palleiro -
Gracias Federico por la respuesta.
El ISP esta usando rip (r11,r12,r13,r14). Cuando ejecutamos traceroute desde server21 a una ip de internet (8.8.8.8) hace la ruta r21,r14, y r11 pero no llega a r3.
Sabemos que esta red no debería ser publicada por rip, pero el comando que encontramos no funcionó. Podrías darnos una mano?
Gracias de antemano
Saludos!
En respuesta a Bruno Stefano Lombardo Palleiro

Re: Entregable 3.1

de Federico Rodriguez -

Una aclaración previa, a la 8.8.8.8 no vas a llegar, dado que el sistema no tiene conexión a Internet.

Sobre la llegada al r3, tenés que analizar las rutas del r11 y de r3, para determinar porqué no lo envía a r3, que es lo que supongo que no está funcionando correcto.

Sobre no publicar por rip, pueden utilizar:

RIP command: passive-interface (IFNAME|default)RIP command: no passive-interface IFNAME

This command sets the specified interface to passive mode. On passive mode interface, all receiving packets are processed as normal and ripd does not send either multicast or unicast RIP packets except to RIP neighbors specified with neighbor command. The interface may be specified as default to make ripd default to passive on all interfaces.

The default is to be passive on all interfaces.

Espero que les sea útil.
Federico 

En respuesta a Federico Rodriguez

Re: Entregable 3.1

de Lucia Thais De Oliveira Gude -
Hola, con respecto a esto, tengo el mismo problema que el compañero, con la misma configuración que el detallo tengo el problema de que el traceroute se queda estancado en r11 y no llega a r3. Pero no creo que sea un problema de configuración ni de r11 ni de r3, ya que haciendo el traceroute desde server12 funciona sin ningun problema. Entiendo que lo que esta trancando son las dos ips iguales (192.168.0.0) en las conexiones. Es la idea que el traceroute desde server21 o 22 a 8.8.8.8 llegue hasta r3? En caso de ser así, podrían darnos alguna idea de como solucionar el problema. Intente varios comandos para que r14 no publique sus rutas privadas, no las publica, y sigo teniendo este problema. Cambiando la ip privada se arregla, entonces entiendo que ese es el problema, pero no encuentro solución. Gracias
En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Leonardo Vidal -
Buenos días.

Si el tráfico del traceroute hacia "internet" (que lo estarían probando con tráfico con dir IP destino 8.8.8.8) queda "estancado" en r11, sería conveniente analizar al menos la tabla de forwarding de r11.
Habría que analizar también a partir de esa tabla y, eventualmente alguna/s otra/s del ISP, porqué el tráfico desde server12 llega y el tráfico desde server21 o server22 no.

Sí, los servidores deben poder ser accedidos desde "internet".

Indico internet entre comillas porque es algo que simulan, eventualmente con alguna interfaz extra definida en r3 y asignándole una IP pública a la misma.

Saludos.
En respuesta a Leonardo Vidal

Re: Entregable 3.1

de Martin Giachino -
Complementando la respuesta de Leo, y respecto al tema de la red "duplicada", todo lo que has hecho va en la línea correcta de manera que si aún el problema persiste (y asumiendo que realmente llegaste a que el problema es ese prefijo) seguramente en algún lugar esa red se te está "colando" aunque tu crees que la removiste de todos los routers. En esos casos, como dice Leo hay que hacer trabajo de hormiga y verificar router por router hasta encontrar en que tabla está, o en que router se te olvidó quitarla.

Martín
En respuesta a Leonardo Vidal

Re: Entregable 3.1

de Lucia Thais De Oliveira Gude -
Hola, contestando a lo que dijo Leonardo, primero, pregunte anteriormente y me dijeron que no es necesario que r3 este realmente conectado a internet, si no que con que llegue el traceroute hasta r3 era suficiente, por lo tanto no entiendo porque seria necesario asignarle una ip publica a r3.
Por otro lado entiendo que en la tabla de forwarding lo que se mira es el destino, no el origen, por lo tanto si un paquete con destino 8.8.8.8 es reenviado a r3 por r11 correctamente, si viene de server 12, no entiendo como podria haber alguna configuracion mal en r11 o en r13 que evitara que se envien paquetes con mismo destino, pero distinto origen, si el origen no entre en juego en la tabla de forwarding.

En respuesta a lo que comento Martin, me fije en las 4 tablas del ISP r11, r12, r13 y r14 y ni r12 ni r13 tienen en sus tablas la direccion 192.168.0.0, solo r11 y r14 como directamente conectadas, es decir, no se esta recibiendo la informacion de las privadas en el resto del ISP como entiendo deberia ser, pero el problema persiste. Puede ser algun problema de la herramienta traceroute? Que no pueda hacer una ruta de un paquete con dos IPs iguales? Porque al fin y al cabo el paquete va a pasar por dos ips iguales en su recorrido.

Si este no es el problema no se que puede ser a esta altura, y despues de dias intentando esto me gustaria saber si no lograr esa conexion entre r11 y r3 es motivo para perder el laboratorio.

Gracias
En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Leonardo Vidal -
Hola Lucía.

Sí, es correcto, no es necesario estar conectado a Internet.

Lo que comenté respecto definir otra interfaz en r3 y asígnarle una IP pública es para tener un más "real" para probar, haciendo un traceroute o un ping a una IP pública configurada en r3 del lado de Internet, y así tener "algo que me responda".
Ello no quiere decir que se deba hacer. Es sólo una idea.

Saludos.
En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Federico Rodriguez -

Lucia,  para resolver el problema está faltando información. Sobre "Pero no creo que sea un problema de configuración ni de r11 ni de r3, ya que haciendo el traceroute desde server12 funciona sin ningun problema.", deberías ver IP origen del traceroute de server12 e IP origen del server2X, y mirando las tablas de forwarding del r11 y r3 analizar que está pasando. 

El traceroute debe llegar hasta r3, que es la salida a la internet ficticia. 

Federico

En respuesta a Federico Rodriguez

Re: Entregable 3.1

de Lucia Thais De Oliveira Gude -
Federico, no habia visto tu respuesta, yo entendi en el curso y de lo leido en el libro que en las tablas de forwarding no se mira la direccion destino, esto no es asi? Hay diferencias dependendiendo de donde viene el paquete? La IP de origen desde server12 es la publica de server 12 y la de los servers 21 y 22 son sus publicas tambien, no entiendo porque habria diferencia en eso
En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Federico Rodriguez -

Lucia, lo que entendiste en el curso es correcto, en la tabla de forwarding se busca la IP destino. Lo que pasa es que para tener una comunicación entre dos entidades conectadas a la red, debe haber camino de ida y camino de vuelta. Puede estar ocurriendo que cuando alguno de los router intenta contestar el traceroute, no tenga éxito, dado que contestará a la IP que fué origen del mensaje.

Entiendo que para ver donde está el problema se debe analizar paso a paso el viaje de los mensajes (ayudandose con tcpdump) y analizar las tablas de forwarding de cada paso.

Te funciona desde server12,  ping y traceroute a server21/server22?

Federico

En respuesta a Federico Rodriguez

Re: Entregable 3.1

de Lucia Thais De Oliveira Gude -
Desde server12 puedo hacer ping y traceroute hacia server21/22 y desde server21/22 puedo hacer ping y traceroute hacia server12. Desde server12 puedo hacer traceroute a 8.8.8.8 y que llegue a r3, y desde r3 hacer traceroute a server12 y que llegue.
Desde server 21 y 22 no llega a r3, pero a r11 llega sin problema, desde r11 puedo llegar a server21/22 pero no puedo llegar de r3 a server21/22, se queda estancado en r11. Mi duda es, si r3 se queda trancado en r11, o sea a r11 llega el mensaje para server21/22 y si r11 sabe llegar sin problema a server21/22, porque el pasamanos entre ellos dos digamos, no funcionaria? Lo mismo hacia el otro lado, he revisado las tablas de r11 varias veces y no entiendo donde podria estar el problema, y porque se arregla cambiando la ip privada de r14/r21.
Gracias
En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Federico Rodriguez -

Lucía, para responder que es lo que está ocurriendo en r11 y r3, disponés de la herramienta tcpdump (wireshark), que te permite ver que paquetes recibió el equipo y cuales generó.

Federico

En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Sebastian Alvarez Falero -
Cuando decís "Desde server 21 y 22 no llega a r3, pero a r11 llega sin problema" te referís a que no estás obteniendo las respuestas de r3, no?
A mi lo que me sucede es que los ICMP request sí llegan a r3, pero la respuesta de r3 se queda por el camino. De hecho, llega a r14 pero por alguna razón no viaja a r21. Sin embargo, un ping de r14 a server21 sí funciona bien. También funcionan los ping entre server2X y server12.

Realmente es desconcertante. Pudieron tener algún avance en eso?
En respuesta a Sebastian Alvarez Falero

Re: Entregable 3.1

de Matias Richart -
Buenas!

Complementando las respuestas de los compañeros docentes, va una lista de ideas para revisar en su solución.
- En primer lugar, deben tener claro el tipo de prueba que están realizando. Tanto traceroute como ping funciona con mensajes de solicitud y respuesta. Es decir que cuando un ping entre 2 nodos nos funciona es porque fué posible que el mensaje de solicitud llegara al nodo destino y el mensaje de respuesta vuelva al nodo origen.
- Por lo tanto, por lo anterior, es necesario que tanto la ruta de origen a destino como la ruta de destino a origen estén bien configuradas.
- Cuando un ping o traceroute "no funciona", esto se puede deber a muchas razones, puede ser que el mensaje de solicitud no esté llegando a destino o que el mensaje de respuesta no pueda "regresar" al origen. Para esto es fundamental capturar los paquetes en los nodos para detectar hasta donde el paquete está llegando y donde se puede estar perdiendo.
- Cuando detectamos donde puede estar el problema, lo primero es revisar la tabla de forwarding. Lo mas probable es que falte una entrada para el destino del paquete que no se está enrutando.
- También es importante revisar que las ips origen y destino de los paquetes que se están generando. En nodos con varias interfaces (como los routers) no siempre es evidente la ip origen con la que se genera (podría ser la de cualquiera de sus interfaces). Esto es importante porque esa ip origen luego será el destino del paquete de respuesta y la que determinará la ruta "de la vuelta".
- En cuanto a las redes privadas 192.168.0.0/30, como ya comentó Federico, esas redes son privadas y para uso en la red entre r3-r11 y r14-r21. Ningún otro nodo conoce la existencia de esa red y no deberían estar en las tablas de forwarding de ningún otro nodo. Por lo tanto, por ejemplo, está mal hacer un ping o traceroute desde server21 a 192.168.0.2, intentando que sea un ping a r3.
- Lo anterior entiendo que es el problema o error que está teniendo la mayoría. La manera de resolverlo es siguiendo la sugerencia de Leonardo, agregar una IP pública en la otra interfaz de r3 y hacer ping a esa IP.

Espero que esto sea de ayuda.
Si siguen con algún inconveniente sugiero que hagan la consulta explicitando la prueba que están haciendo (ping o traceroute con las ips correspondientes), donde el paquete se pierde (o hasta donde llega), ips origen y destino del paquete y la tabla de forwarding del nodo.

Saludos
En respuesta a Matias Richart

Re: Entregable 3.1

de Lucia Thais De Oliveira Gude -
Hola, siguiendo la sugerencia de Leonardo consegui hacer que server2X pueda llegar a r3 haciendo ping o traceroute a esa interfaz publica! Sigo con problemas con la vuelta, es decir de r3 a Server2X, ya identifique el problema: cuando r11 hace ping a Server2X manda el ping con origen 10.0.3.1, y no hay problema, pero cuando r3 hace el ping y tiene que pasar por r11, r11 manda el mensaje a r14 con origen 192.168.0.1, es decir, la interfaz que lo conecta con r3, entiendo que cuando r14 va a contestarle, al el tener directamente conectada en una interfaz esa ip, lo manda ppr ahi y no lo devuelve a r11. Pero la verdad ni estaría viendo forma de solucionarlo, no creo que pueda decirle a r11 que no saque paquetes con el origen privado.

Por otro lado, un traceroute de server2X a r3 no seria suficiente para decir que hay cconexion hacia ambos lados? Por lo que deciaj anteriormente, si r3 no le contestara a server2X no apareceria en el traceroute de server2X a r3, es decirC esto confirma que r3 tiene conexion con los servidores ya no? Es suficiente eso?
En respuesta a Lucia Thais De Oliveira Gude

Re: Entregable 3.1

de Matias Richart -
Hola Lucía.

Bien, creo que encontraste el problema. Cuando hacés un ping desde r3, el paquete sale con origen 192.168.0.1, que debe ser como numeraste la interfaz privada de r3. Como decís, eso implica que no se le pueda responder.
Puedes hacer la prueba de hacer un ping con ip origen la otra interfaz. Eso se hace con la opción -S.

Con respecto a la segunda pregunta, si es suficiente con que funcione el traceroute de server2X a r3.

Saludos
En respuesta a Matias Richart

Re: Entregable 3.1

de Jorge Visca -
Por las dudas en linux el parámetro para ping es -I

-I interface
interface is either an address, an interface name or a VRF name. If interface is
an address, it sets source address to specified interface address. If interface is
an interface name, it sets source interface to specified interface. If interface
is a VRF name, each packet is routed using the corresponding routing table; in
this case, the -I option can be repeated to specify a source address. NOTE: For
IPv6, when doing ping to a link-local scope address, link specification (by the
'%'-notation in destination, or by this option) can be used but it is no longer
required.