sábado, 1 de noviembre de 2014

DNS Spoofing en Kali Linux

Hace ya mucho que no escribo, por lo tanto hoy subiré algo que quizás les interesará para jugar en las redes. Mi idea es demostrar básicamente lo fácil que puede ser aplicar este ataque en redes wifi o cableadas, y lo peligroso que puede ser conectarse a redes abiertas.

Bueno partamos, haciendo DNS SPOOFING la idea es que la resolución de nombres de dominio de un cliente legitimo sean respondidas por nuestra maquina, haciéndose pasar por el verdadero DNS.

¿Qué podemos lograr con esto?
Redireccionar al usuario légitimo a la pagina que nosotros deseemos.
Cuando un usuario intente abrir en su navegador la página www.teleccna.cl la dirección IP real que es 199.34.228.45, pero nuestra maquina responderá y le dirá que la IP 192.168.1.106 es la IP de www.teleccna.cl.
Este es un ejemplo, pero si se realiza este ataque junto a un servidor web que clone la pagina real podría capturar las pass del usuario..

Software necesario:
- Kali Linux ISO (www.kali.org)
- VMware Player (www.vmware.com/cl/products/player)

Paso a paso:

1)  Crear una maquina virtual que inicie con la ISO de Kali Linux. "Create a new Virtual M".
Seleccionar Install disc image file (iso), dar clic en browse y seleccionar el ISO, finalmente dar click en Next.

Damos nombre a la Maquina, y luego Next.

Seleccionamos el tamaño del disco duro de la maquina virtual, con 1 GB basta ya que no la instalaremos, luego dar clic en Next.

Luego clic en Finish, y estamos listos con la maquina virtual.

La maquina se iniciará, arrancando desde la ISO.
2) Dejar en modo Bridge la interface LAN de la maquina Virtual.

Clic en “Player/Removable Device/Network Adaptar/Settings”
Clic en Bridge y luego OK.

3) Iniciar KALI, enter a Live (686-pae).
4) Iniciamos el terminal y editamos el etter.conf con:
nano /etc/ettercap/etter.conf

5) Modificamos los valores dejándolos en:

 ec_uid = 0
 ec_gid = 0

6) Guardamos ( Ctrl + o ) y salimos ( Ctrl + x )

7) Editamos ahora el etter.dns con:
nano /etc/ettercap/etter.dns

8) Agregamos el dominio que queramos direccionar y luego su dirección IP ( www.teleccna.cl A 192.168.0.106 )

9) Guardar y salir

10)   Damos permisos a etter.dns con:
chmod 777 /etc/ettercap/etter.dns
11)   Iniciamos ettercap en aplication/ internet/ Ettercap

12) Damos clic a Sniff/ Unified sniffing y seleccionamos la Interfaz, eth0 en mi caso.
13)   Escaneamos por host, así vemos si hay otros usuarios en la red. Clic en hosts/ Scan for hosts
Luego damos clic en hosts/ host list y nos mostrará los host en la red.

14)   Podemos realizar un ataque seleccionando el Gateway y el host que queramos atacar, seleccionado para Target 1 el Gateway y Target 2 el host a atacar. Si no seleccionamos ningún host, tomará todos los de la red, mejor así ;).

15) Damos clic   MIM/ seleccionamos arp poisoning… y seleccionamos Sniff remote connections y luego OK.
16) Iniciamos el Sniffing en Start.

17) Luego en plugins, damos clic a manage the plugins.

18) Buscamos en la lista dns_spoof y le damos doble clic para inicir el ataque con dns spoof.
Con esto el ataque ya debería haber iniciado, probamos desde nuestra maquina física, iniciando CMD, y ingresando el comando nslookup.

Luego ingresamos el dominio que queramos obtener la dirección IP.

En un inicio nos entregó la IP real, luego al tercer intento nos entregó la IP falsa (192.168.0.106).

Notar que en nuestra maquina virtual también nos arroja que se resolvió el dominio www.teleccna.cl hacia la 192.168.0.106.

Por lo tanto ahora no debería tener acceso a la página de www.teleccna.cl, a menos que la 192.168.0.106 tenga un server web corriendo, después publicaré el paso a paso para levantar el server web incluso clonando una web.

Saludos!

sábado, 28 de junio de 2014

Direccionamiento IPv4 - IPv6 CCNAv5

direccionamiento.pdf
Download File

Picture
En este post realizaré un resumen en general del direccionamiento IP tanto para IPv4 como IPV6. Todo lo exhibido es parte de el capitulo 8 de CCNA1.

Unicast: Comunicación de uno a uno.
Multicast: Comunicación de uno a un grupo especifico.
 Las direcciones reservadas para el grupo multicast son: 224.0.0.0 a la 239.255.255.255.
 Link-local: 224.0.0.0 a 224.0.0.255 utilizadas por protocolos de enrutamiento dinámicos.
Broadcast: Comunicación de uno a todos.

Direcciones privadas:
10.0.0.0 a 10.255.255.255 (10.0.0.0/8) - Clase A mascara por defecto /8
172.16.0.0 a 172.31.255.255 (172.16.0.0/12) - Clase B mascara por defecto /16
192.168.0.0 a 192.168.255.255 (192.168.0.0/16) - Clase C mascara por defecto /24

Dirección de loopback: 127.0.0.1, utilizada para probar el stack de protocolos TCP/IP.
Dirección link-local: 169.254.0.0 a 169.254.255.255 (169.254.0.0/16). Se asigna automáticamente cuando un host no recibe una dirección IP.
Direcciones experimentales: 240.0.0.0 - 255.255.255.254.

Direcciones con clase antigua:

Clase A : 0.0.0.0 a la 127.255.255.255 - Permite 128 redes y aproximadamente 16 millones de host por red.
Clase B: 128.0.0.0 a la 191.255.255.255 - Permite 16384 redes y 65534 hosts por red.
Clase C: 192.0.0.0 a la 223.255.255.255 - Permite 2 millones de redes y 254 host por red.


IPv6

Sucesor de IPv4, motivado principalmente por el agotamiento de direcciones IPv4.
Las direcciones IPv6 poseen 128 bits, se representan en formato Hexadecimal.
Cada digito Hexadecimal posee 4 bits, cada 16 bits o 4 dígitos Hexadecimal se le llama Hexteto.

Dual-stack: Permite en la red tanto IPv4 como IPv6. Los dispositivos de red poseen configurado tanto una dirección IPv4 como IPv6.
Tunneling: Genera un túnel entre redes IPv6 sobre una red IPv4.
NAT64: Permite la comunicación entre redes IPv6 y IPv4.

Reducción de direcciones IPv6.
Los ceros a la izquierda pueden ser omitidos.
Los ceros consecutivos pueden ser escritos con :: solo una vez.

 Ejemplo: 2001:0DB9:0000:0000:ABCD:0000:0000:0100

 1)            2001:0DB9:0000:0000:ABCD:0001:0000:0100
               2001: DB9
:       0:      0:ABCD:       1:       0:  100


2)            2001:DB9::ABCD:1:0:100


Tres tipos de comunicaciones:
Unicast: Comunicación de uno a uno.
Multicast: Comunicación de uno a un grupo especifico. Se encuentran en el rango de FF00::/8.
Por lo tanto siempre partirán con “FF”.
Anycast: Comunicación de uno al mas cercano dentro de un grupo especifico.

NOTA: No existen los broadcast.

En general una dirección IPv6 se divide en dos porciones:
Prefijo (En IPv4 llamada “porción de red”) y ID de interfaz (En IPv4 llamada “Porción de host”).

El ID de interfaz siempre es de 64 bits de largo.                            /64
                                                                                     < PREFIJO | ID de interfaz >
                                             
Direcciones Unicast de IPv6

Unicast Global: Son enrutables hacia Internet, y son únicas globalmente, es decir no se repiten.
Estas direcciones se encuentran en el rango de 2000::/3 a la 3FFF.

Link Local: Direcciones utilizadas para comunicarse con otros dispositivos EN EL MISMO SEGMENTO LAN. Estas direcciones no pueden ser enrutadas fuera de la red Local.

Loopback: ::1/128 o ::1 . Utilizada para probar el stack TCP/IP.

Dirección sin especificar: ::/128 o :: - Utilizada como origen cuando un dispositivo no posee dirección IP.

Local Unica: Similares a las direcciones Privadas de IPv4. No pueden ser enrutadas hacia Internet y se encuentran en el rango de FC00::/7 aFDFF::/7.

Dirección Link-local: FE80::/10 Siempre empiezan con “fe80”, y la porción de ID de interfaz se calcula a partir de la dirección MAC. Se crean automáticamente cuando se le ingresa una dirección IP a Interfaz en un router. También pueden ser configuradas manualmente. Solo permiten comunicación dentro del segmento LAN, no pueden ser enrutadas hacia fuera de la red.

ID de subred: Entre el prefijo /48 al /64 se crean “subredes”. Se muestran en azul en la Imagen.

Dirección IPv6: 2001:1234:5678:ABCD:AAAA:BBBB:CCCC:DDDD
                         
Formas de obtener una dirección IPv6

SLAAC: Permite que un dispositivo final configure su propia IP. Recibe un mensaje “RA” desde un router, donde se incluye “El prefijo (la red) y el gateway predeterminado”. El host al conocer cuál es su red, puede calcular la porción de ID de interfaz (porción de host) automáticamente a partir de su MAC.

DHCPv6: Permite que un dispositivo final reciba una dirección IPv6 para poder comunicarse en la red. “Recibe prefijo de red, su dirección, la dirección del Gateway predeterminado y DNS”.

Proceso EUI-64
Este proceso permite calcular automáticamente la porción de ID de Interfaz a partir de la dirección MAC del dispositivo.

Pasos para calcular porción de ID de interfaz:

1)      Escribir la dirección MAC del dispositivo y separarla en dos justo en el centro:
EJ: A1:B2:C3:D4:E5:F6 -> A1:B2:C3  D4:E5:F6

2)      Introducir los dígitos FF:FFE en el centro:
EJ: A1:B2:C3:FF:FE:D4:E5:F6

3)      El séptimo bit contado de izquierda a derecha se debe mantener en 1.
EJ: A1 -> En binario: 1010 0001 -> 1010 0011 -> A3 -> A3B2:C3FF:FED4:E5F6

4)      Finalmente se debe agregar el prefijo de red:
2000::/64 -> 2000::A3B2:C3FF:FED4:E5F6/64

Direcciones Multicast IPv6 
FF02::1 = “Todos los nodos”, es una dirección que poseen todos los dispositivos de la red. Es similar a la dirección de Broadcast de IPv4.

FF02::2 = “Todos los routers”, es una dirección que poseen todos los routers de la red. Se crean en los routers cuando se ingresa el comando#ipv6 unicast-routing.

FF02::1FF: = Dirección de nodo solicitado. Utilizada para obtener información de un dispositivo, como por ejemplo “obtener la MAC de un dispositivo” (Similar a ARP de IPv4). Empiezan con FF02::1FF: seguido de los últimos 6 dígitos hexadecimales de la dirección IPv6 que se desea resolver.

Ejemplo: Resolver la dirección 2001::AA12:3456 -> FF02::1:FF12:3456


Mensajes ICMPv6:
RS : Mensaje de solicitud de router. Solicita información de la red a un router en la red.
RA: Mensaje de anuncio de router. El router envía información de la red.
NS: Mensaje de solicitud de vecino. Un dispositivo solicita información a otro dispositivo en el segmento de red.
NA: Mensaje de anuncio de vecino. Un dispositivo envía su información al segmento de red.

Comandos para comprobar conectividad:
C:\> Ping 192.168.1.1
C:\> Tracert 192.168.10.7
Router# Traceroute 192.168.10.7
Router# Ping 192.168.10.7

HSRP CCNAv5

La video clase realiza una introducción a los protocolos FHRP, cual es la necesidad de tener un FHRP. Después se aborda HSRP, protocolo propietario de Cisco, con el cual se realiza una práctica en packet tracer para entender su configuración y funcionamiento en la red.


sábado, 14 de junio de 2014

Neighbor Discovery "el reemplazo de ARP para IPv6"

Con el surgimiento de IPv6 se realizaron muchos cambios en comparación a IPv4, uno que me llamó mucho la atención fue la eliminación del BROADCAST, y de ahí que me surgió una gran duda, ¿Qué pasó con los protocolos que funcionaban con BROADCAST?, es decir cómo sería el funcionamiento de ARP o DHCP en una red IPv6, bueno con el estudio de CCNP route empecé a interiorizarme más en este tema y escribiré un poco de cómo funciona la resolución de direcciones IPv6 a MAC.

Neighbor Discovery (ND)
Es la nueva técnica utilizada en IPV6 para descubrir a los vecinos en nuestro segmento LAN, básicamente obtener un mapeo de MAC y dirección IP de un vecino. Es por así decirlo “el reemplazo de ARP para IPV6”, pero no solo tiene este objetivo, también nos servirá en apoyo a otros protocolos como por ejemplo “autoconfigurar una IP con STATELESS”, identificar problemas de direccionamiento en nuestra red, entre otros.
ND se basa en ICMP y utiliza direcciones Multicast (Comunicación de uno a un grupo), y estas direcciones Multicast estarán en el rango de las FF00::/8.

Con ND nacen nuevos mensajes: 
v  NA: Neighbor Advertisement
v  NS: Neighbor Solicitation
v  RA: Router Advertisement
v  RS: Router Solicitation

Neighbor solicitation address 
Cuando trabajamos en un router Cisco con IPv6 las interfaces de los routers pueden tener mas de una dirección IP asignada, y muchas de ellas se crean automáticamente.
Por cada dirección IPv6 configurada en la interfaz (Configurada manual, DHCP, etc), se genera una Multicast FF02::1:FFXX:XXXX, donde XX:XXXX son los últimos 6 hexadecimales de la dirección IPv6 configurada.

Cuando un dispositivo en un segmento LAN desea comunicarse con otro y no posee la dirección MAC, envía un NS a la dirección FF02::1:FFxx:xxxx, donde xx:xxxx son los últimos 6 hexadecimales de la dirección IP destino que se desea obtener la MAC. Le responderán con un NA y se obtendrá la dirección MAC. 

Ejemplo
Se desea realizar un Ping a la dirección IP 2001::1234:5678, la cual es transformada a la  FF02::1:FF34:5678 para utilizarla como destino, y en capa dos el destino será 33.33.FF.34.56.78, es decir 33 33 FF se le agregan los últimos 6 dígitos HEX de la IP.
Imagen
Enviamos un mensaje NS para obtener la dirección MAC de la IP, el Host destino nos responde con un NA, como se ve en el recuadro.
Imagen
Dentro del mensaje NS se encuentra la dirección IPv6 por la que se consulta (al destination utilizado) y enseñándole su propia MAC.
Imagen
Imagen
Como respuesta, dentro del mensaje NA se encuentra la dirección MAC solicitada.

Conclusión 
Nace NDP (Neighbor Discovery Protocol) en IPv6 generando un cambio en los protocolos que funcionaban con broadcast en IPv4. Con respecto a ARP de IPv4, con NDP los host que necesitan obtener la dirección mac envía un NS (Neighbor Solicitation) para preguntar por la MAC y el host final responde con un NA (Neighbor Advertisement) enviando su MAC. La dirección utilizada como destino será una multicast que empieza con FF02::1FFXX:XXX, donde las X representan los últimos 6 dígitos HEX de la dirección IPv6 que se desea obtener la MAC, y en capa 2 33.33.FF.XX.XX.XX.

Finalmente con la respuesta ya podemos llenar nuestra tabla de vecinos, y así finalmente poder comunicarlos con los host de nuestra red. 

viernes, 6 de junio de 2014

Este es un resumen que escribí hace algún tiempo sobre EIGRP, cuando me preparaba para mis exámenes. En general es un resumen echo a partir del libro oficial de Cisco 642-902. Espero que a los que estén preparándose para nuevos desafíos les pueda servir. Saludos!
eigrp_resumen.pdf
Download File

Imagen
Imagen
Imagen
Imagen

martes, 11 de febrero de 2014

Sumarización con protocolos de enrutamiento dinámicos

La sumarización de redes es una técnica que nos sirve para optimizar los recursos de los routers, además de que nos permite mantener una red menos compleja y más estable.
Cuando trabajamos con protocolos de enrutamiento dinámicos como Rip o Eigrp, nos aconsejan siempre desactivar la sumarización automática, a pesar de que al mismo tiempo nos dicen "Sumarizar es bueno". Esto genera una confusión al momentos de estudiar como funciona esto, y porque nos aconsejan siempre realizar una sumarización manual de las rutas.

En este tutorial les explicare los problemas que ocurren cuando no se desactiva, donde se debe realizar la sumarización en una topología con distintos protocolos de enrutamiento, y en que nos ayuda esto.

Sumarización en protocolos de enrutamiento dinámicos

Lo primero que debemos saber es que existen protocolos de enrutamiento que realizan la sumarización automática y otros que no, en la siguiente tabla se muestran:
Imagen
Tomaremos para los ejemplos estos protocolos ya que son los mas utilizados en CCNA.
Cada protocolo posee un tipo de métrica distinta, ademas de que el diseño de una red para cada uno es distinto.
Por ejemplo, OSPF exige una arquitectura jerárquica, donde cada área debe ir conectada al área 0, al contrario de EIGRP donde la jerarquía no es importante. Esto es importante, ya que al momento de sumarizar, debemos saber en que router y cuando realizar la sumarización.

Sin embargo, en general la sumarización obedece una regla que dice "La sumarización debe ser realizada en los routers borde".
Por lo tanto quiere decir que Rip y Eigrp siempre sumarizaran automáticamente en estos routers. Pero la duda es ¿Como se cual es un router borde en mi red?. 

Routers borde

En general entendemos como router borde, el router encargado de interconectarnos con el exterior de nuestra red. Pero un router borde no es solo eso. Un protocolo de enrutamiento entiende como router borde, al router que posee dos redes distintas conectadas, dos protocolos de enrutamiento distintos, o para OSPF un ABR o un ASBR.

Router borde en RIP y EIGRP

Rip y Eigrp realizan sumarización automática en los router que poseen "Dos redes distintas", quizás suena obvio, ya que normalmente todos los routers poseen mas de una red conectada. Sin embargo esto es lo que produce la confusión, ya que un router cuando posee dos SUBREDES que pertenecen a la misma RED no sumariza automáticamente, por lo tanto no es tomado como "Router Borde".

Si un router posee la siguientes redes 10.0.0.0/24 y 10.0.1.0/24
No sumarizará automáticamente, ya que ambas pertenecen a la 10.0.0.0/8.

Si un router posee las redes 172.16.0.0/24. y 172.17.0.0/24
Si sumarizará automáticamente, ya que pertenecen a distintas redes, es decir 172.16.0.0/16 y 172.17.0.0/16.

Si las redes pertenecen a la clase A respetará el prefijjo /8 para las redes
Si las redes pertenecen a la clase B respetará el prefijo /16 y para la clase C el prefijo /24.

Si las redes no se encuentran dentro de una misma red con el prefijo correspondiente, el router será tomado como borde para EIGRP y Rip.

Ejemplo:

Imagen
ROUTER R1
Para Eigrp y Rip será router borde, ya que posee distintas redes, es decir:
CLASE A -> PREFIJO /8
10.0.0.0/8 y 11.0.0.0/8 no pertenecen a la misma red, por lo tanto es tomado como router borde.

ROUTER R2
CLASE A -> PREFIJO /8
Posee las redes 11.0.0.4/30 y 11.0.0.0/30 -> Ambas pertenecen a la red 11.0.0.0/8, por lo tanto no sumariza automáticamente.

ROUTER R3
CLASE A -> PREFIJO /8
Redes 11.0.0.0/8 y 12.0.0.0/8 -> No pertenecen a la misma red, por lo tanto es router borde (sumariza automáticamente).

Como son routers borde, envían sus redes sumarizadas.
R1 tiene la red 10.0.1.0/24, pero la envía a R2 como 10.0.0.0/8
R2 tiene la red 12.0.1.0/24, pero la envía a R2 como 12.0.0.0/8

En esta topología no existe problema, por lo tanto no es necesario desactivar la sumarizacion automática, pero existen casos para los cuales si es necesario.

Sumarización con RIP

La sumarización en RIP se debe realizar en la interfaz conectada al router al que le queremos anunciar la red Sumarizada.
En modo configuración de interfaz aplicamos el comando:
ip summary-address rip "red-sumarizada" "mascara"

Ejemplo:
R1 desea anunciar sus redes directamente conectadas con prefijo /24
Imagen
Si realizamos un Show ip route en R2, nos damos cuenta que las redes son anunciadas individualmente
Imagen
En R1 realizamos la sumarización de las 4 redes, con el comando ip summary-address rip 172.16.0.0 255.255.252.0 en modo configuración de interfaz.
Imagen
Finalmente verificamos en R2 con el comando Show ip route. Ahora vemos que nos anuncia solo una RED sumarizada.
Imagen

Sumarización con EIGRP

Al igual que en RIP la sumarización de EIGRP debe realizarse en la interfaz conectada al router que deseamos anunciar las redes sumarizadas.
En modo configuración de interfaz aplicamos el comando:
ip summary-address EIGRP "Sistema-autónomo" "RED SUMARIZADA" "MASCARA"

Ejemplo:
Imagen
Realizamos un show ip route en R2 para verificar las redes que son anunciadas desde R1
Imagen
Luego sumarizamos las redes, en modo configuración de interfaz con el comando ip summary-address eigrp 1 172.16.0.0 255.255.252.0
Imagen
Finalmente verificamos que R2 posea la red sumarizada como el comando show ip route
Imagen

Sumarización con OSPF

OSPF obedece una arquitectura jerárquica, donde las área ordinarias deben ir conectadas al área backbone (área 0). Los router que interconecten las areas ordinarias (área distintas a 0) al area 0, se les llama ABR. Si un router perteneciente a OSPF interconecta otras redes pertenecientes a otro sistema autónomo, se les llama ASBR.

Al momento de sumarizar esto es importante, ya que la sumarización solo se debe realizar en los ABR y ASBR.
Para realizar la sumarización debemos ingresar en la configuración de OSPF y aplicar el comando:
Area "Area-ID " range "RED-SUMARIZADA" "MASCARA"

Ejemplo:
Imagen
En esta topología R1 es un ABR, por lo tanto será aquí donde realizaremos la sumarización. El objetico es que las redes ingresen sumarizadas al area 0.
Imagen
Primer verificamos en R2 las redes que son anunciadas por R1 con el comando Show ip route.
Imagen
Ingresamos a la configuración de OSPF y con el comando area 1 range 172.16.0.0 255.255.252.0 realizamos la la sumarización.
En el comando utilizamos AREA 1 ya que las redes que deseamos sumarizar pertenecen al AREA 1.
Imagen
Finalmente verificamos la sumarización con el comando show ip route en R2

Problemas con sumarización automatica

Como comenté anteriormente, la sumarizacion automática se genera en routers borde. Existen veces en que no queremos que esto suceda, ya que nos trae grandes problemas. A continuación les mostraré una topología para verificar el problema que ocurre al dejar la sumarización automática.

Topología:
Imagen
En esta topología podemos identificar el problema que ocurre con la sumarizacion automática cuando trabajamos con RIP. Lo mismo ocurre con EIGRP, si dejamos la sumarizacion automatica activada. 
Todos los router corren RIP en todas sus interfaces.
1)Router R1 decide anunciar su red 172.16.1.0/24 a R2, pero como se da cuenta que posee dos redes distintas, es decir 172.16.0.0/16 y 192.168.1.0/24, se da cuenta que es un router borde, y la anuncia sumarizada.

2)Router R1 anuncia la red como 172.16.0.0/16 a R2.

3)Router R3 también se da cuenta que es un router borde, ya que posee dos redes distintas, es decir la 192.168.1.0/24 y la 172.16.0.0/16.

4)Router R3 anuncia la red como 172.16.0.0/16 a R2

5)Router R2 recibe la misma red (172.16.0.0/16) por ambos lados, el costo por ambos lados es el mismo, por lo tanto se balancea carga.
Imagen
6) Cuando la LAN de R1 quiera comunicarse con la LAN de R3, el trafico será enviado a R2.
R1 mira su tabla de enrutamiento y decide seguir la ruta de 172.16.0.0/16
Imagen
7) R2 recibe el paquete, ve que va destinado a la red 172.16.2.0, revisa en su tabla de enrutamiento y ve que recibe la red 172.16.0.0 por ambos lados. R2 decide utilizar como siguiente salto la 192.168.1.1, volviendo a enviar el paquete a R1.
Imagen
8) R1 recibe el paquete y se lo vuelve a enviar a R2.
9) R2 revisa en su tabla de enrutamiento, y ahora decide utilizar el siguiente salto 192.168.1.6, ya que  balancea trafico.
10) R3 recibe el paquete y lo envía a la LAN.

Esto sucede para todo el trafico que viaja entre las LAN, esto podría generar un loop o un enrutamiento suboptimo, por lo tanto se aconseja en estos casos desactivar la sumarización automática., con el comando no auto-summary en la configuración de RIP.


Aplicamos este comando en R1 y R3.
Visualizamos con el comando show ip route, y vemos que las redes ahora aparecen en R2, y ya no existe balanceo de carga. Por lo tanto se ha solucionado el problema.
Imagen
Este mismo problema podría ocurrir con EIGRP, ya que el costo por ambos enlaces seria igual. Por lo tanto en estos casos se aconseja desactivar la sumarización automática.