Anda di halaman 1dari 56

Exposición Capítulo 7 RIPv2

Expositores:
- Neftalí olan arias.
-Daniel Cortázar estrada
Capítulo 7 RIPv2
RIPv2 es un protocolo de enrutamiento apropiado para algunos
ambientes, pierde popularidad cuando se compara con protocolos de
enrutamiento tales como EIGRP, OSPF e ISIS, que ofrecen más
funciones y son más escalables. las diferencias entre un protocolo de
enrutamiento con clase (RIPv1) y un protocolo de enrutamiento sin
clase (RIPv2)

Los protocolos de enrutamiento con clase no incluyen la máscara de


subred con la dirección de red en las actualizaciones de enrutamiento,
lo que puede ocasionar problemas con las redes o subredes no
contiguas que usan la Máscara de subred de longitud variable
(VLSM).

Como RIPv2 es un protocolo de enrutamiento sin clase, las máscaras


de subred se incluyen en las actualizaciones de enrutamiento, lo que
hace que RIPv2 sea más compatible con los ambientes de
enrutamiento modernos.
RIPv2 sus funciones mejoradas incluyen:

 Direcciones de siguiente salto incluidas en las


actualizaciones de enrutamiento
 Uso de direcciones multicast al enviar
actualizaciones
 Opción de autenticación disponible

RIPv2 es un protocolo de enrutamiento por vector


de distancia.
 Uso de temporizadores de espera y otros
temporizadores para ayudar a impedir routing
loops.
 Uso de horizonte dividido u horizonte dividido
con envenenamiento en reversa para ayudar
también a impedir routing loops.
 Uso de updates disparados cuando hay un
cambio en la topología para lograr una
convergencia más rápida.
Limitaciones de RIPv1
Recuerde que los routers R1 y R3 tienen
subredes que forman parte de la red
principal con clase 172.30.0.0/16 (clase B).
También recuerde que R1 y R3 están
conectados a R2 con subredes de la red
principal con clase 209.165.200.0/24
(clase C).

Esta topología es no contigua y no


convergerá porque 172.30.0.0/16 está
dividida por 209.165.200.0/24.
La topología muestra que R2 tiene una
ruta resumida estática hacia la red
observe que los routers R1 y R3 contienen redes VLSM
y comparten el espacio de dirección de la red principal
con clase 172.30.0.0/16.
Podemos inyectar información de rutas
estáticas en las actualizaciones de
protocolo de enrutamiento esto se
denomina “redistribución”.
VLSM
Como se muestra en el gráfico superior, tanto R1
como R3 han dividido la red 172.30.0.0/16 en
subredes de /24.

Cuatro de estas subredes de /24 se asignan: dos a


R1 (172.30.1.0/24 y 172.30.2.0/24) y dos a R3
(172.30.100.0/24 y 172.30.110.0/24).

En la parte inferior del gráfico, hemos tomado la


subred 172.30.200.0/24 y la hemos subdividido
nuevamente, usando los primeros cuatro bits
para las subredes y los cuatro últimos bits para
los hosts.
El resultado es una máscara de 255.255.255.240
o de /28.
La Subred 1 y la Subred 2 se asignan a R3. Esto
significa que la subred 172.30.200.0/24 ya no
En la tabla se muestran las direcciones
que cumplen con RFC 1918. Pero
cuando se realiza el enrutamiento
del tráfico IP por los enlaces WAN a
través de un ISP o cuando los
usuarios internos necesitan ingresar
en sitios externos, debe usarse una
dirección IP pública.
Direcciones IP de un ejemplo
de Cisco
Los enlaces WAN entre R1, R2 y R3 utilizan
direcciones IP públicas. Si bien según la RFC
1918, estas direcciones IP no son direcciones
privadas, Cisco ha adquirido un cierto espacio
de direcciones públicas para usar con los
ejemplos.

Las direcciones que se muestran en la figura son


todas direcciones IP públicas válidas con las
que se puede realizar el enrutamiento en
Internet.
El R1, R2 y R3 se conectan usando el espacio de
direcciones públicas de Cisco
209.165.200.224/27.
Debido a que los enlaces WAN sólo necesitan dos
direcciones, la 209.165.200.224/27 se
subdivide en subredes con una máscara de /30.
Interfaces loopback
R3 utiliza interfaces loopback (Lo0, Lo1 y Lo2). Una
interfaz loopback es una interfaz de software que se
usa para emular una interfaz física. Como a otras
interfaces, se le puede asignar una dirección IP.

Otros protocolos de enrutamiento, tales como OSPF,


también usan las interfaces loopback para distintos
fines.

Las interfaces loopback son útiles para crear redes


adicionales sin tener que agregar más interfaces
físicas al router. Se puede hacer ping en una interfaz
loopback y la subred puede publicarse en las
actualizaciones de enrutamiento.

Por lo tanto, las interfaces loopback son ideales para


simular múltiples redes conectadas al mismo router.
En nuestro ejemplo, R3 no necesita cuatro interfaces
LAN para realizar una demostración de múltiples
subredes y VLSM. En cambio, usamos interfaces
Limitaciones de
topología
Rutas estáticas RIPv1
e interfaces nulas
Para configurar la ruta de superred estática en R2, se usa
el siguiente comando:
R2(config)#ip route 192.168.0.0 255.255.0.0 Null0

El resumen de ruta permite una única entrada de ruta de


alto nivel para representar muchas rutas de nivel bajo
y reducir el tamaño de las tablas de enrutamiento. La
ruta estática de R2 usa una máscara de /16 para
resumir las 256 redes comprendidas entre
192.168.0.0/24 y 192.168.255.0/24.

El espacio de dirección que representa la ruta resumida


estática 192.168.0.0/16 en realidad no existe. Para
simular esta ruta estática, usamos una interfaz nula
como interfaz de salida. No es necesario que usted
ingrese ningún comando para crear o configurar la
interfaz nula. Siempre se encuentra activa pero no
reenvía ni recibe tráfico.
El tráfico que se envía a la interfaz nula se desecha. Para
nuestros fines, la interfaz nula servirá de interfaz de
salida de la ruta estática. Recuerde del Capítulo 2,
"Enrutamiento estático", que una ruta estática debe
tener una interfaz de salida activa antes de ser instalada
en la tabla de enrutamiento. El uso de la interfaz nula
permitirá a R2 publicar la ruta estática en RIP a pesar de
que las redes que pertenecen al resumen
192.168.0.0/16 en realidad no existen.

Redistribución de ruta
El segundo comando que debe ingresarse es el comando
redistribute static:
R2(configrouter)# redistribute static
La redistribución implica tomar las rutas de una fuente de
enrutamiento y enviarlas a otra fuente de enrutamiento.
En nuestra topología de ejemplo, queremos que el
proceso RIP en R2 redistribuya nuestra ruta estática
(192.168.0.0/16) importando la ruta en RIP y luego
Verificación y prueba de conectividad
Para probar si la topología tiene conectividad
completa, primero verificamos que los dos
enlaces seriales de R2 estén activos usando el
comando show ip interface brief como se
muestra en la figura para los enlaces de R2.
Si un enlace está desactivado, el campo Estado o
el campo Protocolo (o ambos) mostrarán Down
(desactivado) en el resultado del comando. Si
un enlace está activado, ambos campos
mostrarán up, como se muestra aquí. R2 tiene
conectividad directa a R1 y R3 por los enlaces
seriales.

Pero ¿puede R2 hacer ping en las LAN de R1 y


R3? ¿Hay algún problema de conectividad con
un protocolo de enrutamiento con clase y las
subredes no contiguas de 172.30.0.0?
R2 intentando hacer ping en la interfaz 172.30.1.1 de R1 y en la
interfaz 172.30.100.1 de R3.

Cuando R2 hace ping en cualquiera de las subredes 172.30.0.0 de


R1 o R3, sólo aproximadamente el 50% de los mensajes ICMP son
exitosos.
R1 puede hacer ping en 10.1.0.1, pero no tiene éxito
cuando intenta hacer ping en la interfaz 172.30.100.1 de
R3.
R3 puede hacer ping en 10.1.0.1, pero no tiene éxito cuando intenta
hacer ping en la interfaz 172.30.1.1 de R1.

Como puede ver, hay un problema obvio cuando intenta


comunicarse con las subredes no contiguas 172.30.0.0. En las
siguientes secciones examinaremos las tablas de enrutamiento y
actualizaciones de enrutamiento para investigar más este problema
e intentar resolverlo.
RIPv1: redes no
contiguas
RIPv1 es un protocolo de enrutamiento
con clase. Como puede ver en el
formato de mensaje del RIPv1, en sus
actualizaciones de enrutamiento no se
incluyen las máscaras de subred. Por
lo tanto, RIPv1 no puede admitir redes
no contiguas, VLSM ni superredes
Classless InterDomain Routing (CIDR).
Debido a que la máscara de subred no está incluida en la actualización,
RIPv1 y otros protocolos de enrutamiento con clase deben resumir las
redes en los bordes de redes principales.

Como puede ver en la figura, el RIPv1 de los routers R1 y R3 resumirá


sus subredes 172.30.0.0 a la dirección con clase de red principal de
172.30.0.0 cuando envíe actualizaciones de enrutamiento a R2. Desde la
perspectiva de R2, ambas actualizaciones tienen el mismo costo de 1
salto para alcanzar la red 172.30.0.0/16. Como verá, R2 instala ambas
rutas en la tabla de enrutamiento.
Examen de las tablas de
enrutamiento
R2 obtiene resultados incoherentes cuando
intenta hacer ping en la dirección en una
de las subredes 172.30.0.0.
Observe que R2 tiene dos rutas de igual costo hacia la red 172.30.0.0/16.
Esto se debe a que tanto R1 como R3 están enviando a R2 una
actualización RIPv1 para la red con clase 172.30.0.0/16 con una métrica de
1 salto. Como R1 y R3 resumieron automáticamente las subredes
individuales, la tabla de enrutamiento de R2 sólo contiene la red principal
con clase de 172.30.0.0/16.
Podemos examinar los contenidos de las actualizaciones de enrutamiento
ya que las actualizaciones se envían y reciben con el comando debug ip rip.
El resultado de este comando muestra que R2 recibe dos rutas de igual
costo 172.30.0.0 con una métrica de 1 salto. R2 recibe una única ruta
en Serial 0/0/0 desde R1 y otra ruta en Serial 0/0/1 desde R3. Observe
que la máscara de subred no se incluye con la dirección de red en la
actualización.
R1 tiene sus propias rutas 172.30.0.0: 172.30.2.0/24 y 172.30.1.0/24.
Pero R1 no envía esas subredes a R2. R3 tiene una tabla de
enrutamiento similar. Tanto R1 como R3 son routers de borde y sólo
envían la red 172.30.0.0
resumida a R2 en sus actualizaciones de enrutamiento de RIPv1.
Por ende, R2 sólo conoce la red con clase 172.30.0.0/16 y no tiene
conocimiento de ninguna subred 172.30.0.0.
Observe en el resultado de debug ip rip de R2 que no incluye la red
172.30.0.0 en sus actualizaciones a R1 ni a R3.
¿Por qué no? Porque tiene vigencia la regla de horizonte dividido. R2
ha detectado a 172.30.0.0/16 en las interfaces Serial 0/0/0 y Serial
0/0/1. Debido a que R2 detectó a 172.30.0.0 en estas interfaces, no
incluye esa red en las actualizaciones que envía desde estas mismas
interfaces.
RIPv1: Incompatibilidad con
VLSM
Debido a que RIPv1 no envía la máscara de subred
en las actualizaciones de enrutamiento, no puede
admitir VLSM. El router R3 está configurado con
las subredes VLSM, que son miembros de la red
clase B 172.30.0.0/16:

 172.30.100.0/24 (FastEthernet 0/0)


 172.30.110.0/24 (Loopback 0)
 172.30.200.16/28 (Loopback 1)
 172.30.200.32/28 (Loopback 2)
Para demostrar de qué manera RIPv1 usa la máscara de subred de la interfaz
saliente, R4 se agrega a la topología conectada a R3 a través de la interfaz
FastEthernet0/0 en la red 172.30.100.0/24.
Observe que la única subred 172.30.0.0 que se envía al router
R4 es 172.30.110.0. Y que R3 envía toda la red principal
con clase 172.30.0.0 de Serial 0/0/1.
Esas subredes no tienen la misma máscara de subred que
FastEthernet 0/0. Por eso todas las subredes deben usar la
misma máscara de subred cuando se implementa un
protocolo de enrutamiento con clase en la red.
El R3 necesita determinar qué subredes 172.30.0.0 incluir en
las actualizaciones que salen de su interfaz FastEthernet 0/0
con la dirección IP 172.30.100.1/24. Sólo incluirá esas rutas
172.30.0.0 en su tabla de enrutamiento con la misma
máscara que la interfaz de salida. Debido a que la interfaz
es 172.30.100.1 con una máscara de /24, sólo incluirá
subredes 172.30.0.0 con una máscara de /24. La única que
cumple con esta condición es 172.30.110.0.
Las otras subredes 172.30.0.0, 172.30.200.16/28 y
172.30.200.32/28, no se incluyen porque las máscaras de
/28 no coinciden con la máscara de /24 de la interfaz
saliente. El router receptor, R4, sólo puede aplicar su propia
máscara de interfaz de /24 a las notificaciones de la ruta de
RIPv1: Incompatibilidad
con CIDR

una ruta estática hacia la red 192.168.0.0/16 de R2 y le


ordenamos a RIP que incluya esa ruta en sus actualizaciones
con el comando redistribute static, como se muestra en la
figura.
Esta ruta estática es un resumen de las subredes
192.168.0.0/24 comprendidas entre 192.168.0.0/24 y
192.168.255.0/24. R2(config)#ip route 192.168.0.0
255.255.0.0 Null0
R1 no está recibiendo la ruta 192.168.0.0/16 en sus actualizaciones de RIP de
R2, si bien nosotros esperábamos que sí lo estuviera haciendo.
Configuramos la ruta estática 192.168.0.0 con una máscara de /16.
Ésta tiene menos bits que la máscara de clase C con clase de /24.
Debido a que la máscara no coincide con la clase ni la subred de la
clase, RIPv1 no incluirá esta ruta en sus actualizaciones a otros
routers.
RIPv1 y otros protocolos de enrutamiento con clase no pueden admitir
rutas CIDR que sean rutas resumidas con una máscara de subred
menor que la máscara con clase de la ruta. RIPv1 ignora estas
subredes en la tabla de enrutamiento y no las incluye en las
actualizaciones a otros routers. Esto se debe a que el router receptor
sólo podrá aplicar la máscara con clase más grande a la actualización
y no la máscara de /16 más corta.
Configuración del RIPv2
Habilitación y verificación del
RIPv2
RIPv2 se define en RFC 1723. RIPv2 se encapsula en
un segmento UDP mediante el puerto 520 y
puede transportar hasta 25 rutas.
La primera extensión en el formato de mensaje de
RIPv2 es el campo de la máscara de subred que
permite que una máscara de 32 bits se incluya en
la entrada de ruta de RIP. El router receptor ya no
depende de la máscara de subred de la interfaz
entrante ni de la máscara con clase al determinar
la máscara de subred para una ruta.
La segunda extensión importante para el formato
de mensaje de RIPv2 es la adición de la dirección
del siguiente salto. La dirección del siguiente
salto se usa para identificar una dirección del
siguiente salto mejor que la dirección del router
El comando show ip protocols verifica que R2 esté configurado para RIPv1,
pero recibe mensajes de RIP para ambas versiones.
Se utiliza para el router r2,r3 de la misma manera.
Este comando debe configurarse en todos los routers del dominio de
enrutamiento.
Se utiliza para el router r2,r3 de la misma manera.
Verificación de las actualizaciones de
RIPv2
La tabla de enrutamiento de R2 ahora
contiene las subredes individuales para
172.30.0.0/16. Observe que ya no hay una
única ruta resumida con dos rutas de igual
costo.
VLSM y CIDR
Debido a que los protocolos de enrutamiento sin
clase como RIPv2 pueden transportar la dirección
de red y la máscara de subred, no necesitan
resumir estas redes a sus direcciones con clase
en los bordes de redes principales. Por lo tanto,
los protocolos de enrutamiento sin clase admiten
VLSM. Los routers que usan RIPv2 ya no
necesitan usar la máscara de la interfaz saliente
para determinar la máscara de subred en la
notificación de la ruta.
En las redes que usan un esquema de
direccionamiento VLSM, un protocolo de
enrutamiento sin clase es esencial para propagar
todas las redes junto con las máscaras de subred
correctas. Si observamos el resultado de debug ip
rip para R3 en la figura, podemos ver que RIPv2
RIPv2 y CIDR
Una superred es un bloque de redes con clase contiguas que se
direcciona como una única red. En el router R2,configuramos una
superred, una ruta estática a una única red que se usa para
representar varias redes o subredes.
Las superredes tienen máscaras que son más pequeñas que la
máscara con clase (de /16 en este caso, en lugar de la máscara
con clase de /24). Para que la superred se incluya en una
actualización de enrutamiento, el protocolo de enrutamiento debe
tener la capacidad de transportar esa máscara. Es decir que debe
ser un protocolo de enrutamiento sin clase, como RIPv2.
La ruta estática de R2 sí incluye una máscara que es menor que la
máscara con clase:
R2(config)#ip route 192.168.0.0 255.255.0.0 Null0
En un ambiente con clase, la dirección de red 192.168.0.0 se asocia
con la máscara clase C con clase de /24 ó 255.255.255.0.
En las redes actuales, ya no relacionamos las direcciones de red con
las máscaras con clase. En este ejemplo, la red 192.168.0.0 tiene
una máscara de /16 ó 255.255.0.0. Esta ruta puede representar
una serie de redes 192.168.0.0/24 o cualquier número de distintos
Verificación y resolución de problemas del
RIPv2
Comandos para la verificación y resolución de
problemas
Existen muchas formas de verificar y resolver los
problemas de RIPv2. Muchos de los mismos
comandos que se usan para RIPv2 pueden
utilizarse para verificar y resolver los problemas
de otros protocolos de enrutamiento.
Siempre se recomienda comenzar con los principios
básicos:
1. Asegúrese de que todos los enlaces (interfaces)
estén activados y en funcionamiento.
2. Verifique el cableado.
3. Verifique que tiene la máscara de subred y
dirección IP correcta en cada interfaz.
4. Elimine los comandos de configuración que sean
innecesarios o se hayan reemplazado con otros
verificar la convergencia de red

Si está faltando una red en la tabla de enrutamiento, generalmente es


porque una interfaz está desactivada o mal configurada. El comando show
ip interface brief verifica rápidamente el estado de todas las interfaces.
El comando show ip protocols verifica varios elementos esenciales y también
verifica que RIP esté habilitado, la versión de RIP, el estado del resumen
automático y las redes que se incluyeron en las sentencias de red.
debug ip rip es un excelente comando para examinar los contenidos
delas actualizaciones de enrutamiento que un router envía y recibe.
Es posible que en algún momento un router reciba una ruta pero no
la agregue en la tabla de enrutamiento.

Una manera fácil de verificar la conectividad completa es con el


comando ping. Si la conectividad de extremo a extremo no es
satisfactoria, comience haciendo ping en las interfaces locales. Si es
satisfactoria, haga ping en las interfaces del router en las redes
conectadas directamente. Si eso también es satisfactorio, continúe
haciendo ping en las interfaces de cada router sucesivo. Una vez que
un ping no es satisfactorio, examine ambos routers y todos los
routers intermedios para determinar dónde y por qué está fallando el
ping.
El comando show runningconfig puede usarse para verificar todos los
comandos configurados en ese momento.

Generalmente, otros comandos son más eficientes y proporcionan más


información que una simple lista de la configuración actual. Sin embargo, show
runningconfig es útil para determinar si un elemento esencial se ha olvidado o
está mal configurado.
Autenticación
La mayoría de los protocolos de enrutamiento envían
sus actualizaciones y otra información de
enrutamiento con IP(en paquetes IP). El ISIS es la
excepción más evidente y se discute en los cursos
de CCNP.
Uno de los problemas de seguridad en cualquier
protocolo de enrutamiento es la posibilidad de
aceptar actualizaciones de enrutamiento inválidas.
La puente de estas actualizaciones de enrutamiento
inválidas puede ser un atacante que intenta
maliciosamente afectar la red o capturar paquetes
engañando al router para que envíe sus
actualizaciones al destino equivocado. Otra fuente
de actualizaciones inválidas puede ser un router mal
configurado. O bien puede ser que un host esté