Exposición Capítulo 7 RIPv2

Expositores:- Neftalí olan arias.

-Daniel Cortázar estrada

Capítulo 7 RIPv2RIPv2 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.

Límite máximo en el conteo de saltos de 15 saltos, con el conteo de saltos de 16 que expresa una red inalcanzable.

Limitaciones de RIPv1Recuerde 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 192.168.0.0/16.

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”.

VLSMComo 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 puede usarse, a pesar de que las subredes de /28 restantes pueden usarse.

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 CiscoLos 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. En la topología, la subred 1 se asigna al enlace WAN entre R1 y R2.

La subred 2 se asigna al enlace WAN entre R2 y R3.

Interfaces loopbackR3 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 loopback.

Limitaciones de topología RIPv1Rutas estáticas e interfaces nulasPara 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 rutaEl segundo comando que debe ingresarse es el comando redistribute

static:R2(configrouter)# redistribute staticLa 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 enviándola a R1 y R3 mediante el proceso RIP. Veremos si en realidad esto está sucediendo y de no ser así, por qué.

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? Probemos las comunicaciones entre los routers usando ping.

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 contiguasRIPv1 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 enrutamientoR2 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.0resumida 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 VLSMDebido 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 con subredes 172.30.0.0. Con máscaras de /28, R4 aplicaría la máscara de /24 incorrecta a estas subredes.

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 RIPv2Habilitació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 emisor, si es que existe.

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 CIDRDebido 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 incluye las redes y sus máscaras de subred en las actualizaciones de enrutamiento.

RIPv2 y CIDRUna 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 Null0En 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 rangos de direcciones. La única forma en la que puede incluirse esta ruta en una actualización de enrutamiento dinámica es con un protocolo de enrutamiento sin clase que incluya la máscara de /16.

Verificación y resolución de problemas del RIPv2Comandos 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 comandos.

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ónLa 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é conectado a la red y, sin que el usuario lo sepa, el host ejecuta el protocolo de enrutamiento de la red local.