Escolar Documentos
Profissional Documentos
Cultura Documentos
7. RIPv2.
7.0 Introducción del capítulo.
7.0.1 Introducción del capítulo.
La versión 2 de RIP (RIPv2) se define en RFC 1723. Éste es el primer protocolo de enrutamiento sin
clase que se discute en el curso. La figura ubica a RIPv2 en su propia perspectiva con respecto a otros
protocolos de enrutamiento. Si bien RIPv2 es un protocolo de enrutamiento apropiado para algunos
ambientes, pierde popularidad cuando se compara con protocolos de enrutamiento tales como EIGRP,
OSPF e IS-IS, que ofrecen más funciones y son más escalables.
Aunque puede ser menos popular que otros protocolos de enrutamiento, ambas versiones de RIP aún son
apropiadas para algunas situaciones. Si bien RIP carece de las capacidades de muchos protocolos
posteriores, su simplicidad y amplia utilización en varios sistemas operativos lo convierten en un
candidato ideal para las redes homogéneas más pequeñas, donde es necesaria la compatibilidad con varios
fabricantes, especialmente dentro de los ambientes UNIX.
Debido a que necesitará entender RIPv2, incluso si no lo usa, este capítulo se concentrará en las
diferencias entre un protocolo de enrutamiento con clase (RIPv1) y un protocolo de enrutamiento sin
clase (RIPv2), más que en los detalles de RIPv2. La limitación principal de RIPv1 es que es un protocolo
de enrutamiento con clase. Como usted sabe, 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.
En realidad, RIPv2 es una mejora de las funciones y extensiones de RIPv1, más que un protocolo
completamente nuevo. Algunas de estas 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
Como RIPv1, RIPv2 es un protocolo de enrutamiento por vector de distancia. Las dos versiones de RIP
tienen las siguientes funciones y limitaciones:
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.
VLSM
Revise el esquema de direccionamiento VLSM de la figura. 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 puede usarse, a pesar de que las subredes de /28 restantes
pueden usarse.
Interfaces loopback
Observe que 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. Estos usos se discutirán en el Capítulo 11, OSPF.
En un ambiente de laboratorio, 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.
Enlaces
"Internet Assigned Numbers Authority" (Autoridad de Números Asignados de Internet),
http://www.iana.org/
"Configuring Logical Interfaces" (Configuración de interfaces lógicas),
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a
0080087da4.html
R2(config-router)#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 enviándola a R1 y R3 mediante el
proceso RIP. Veremos si en realidad esto está sucediendo y de no ser así, por qué.
Enlaces
"Configuring Logical Interfaces" (Configuración de interfaces lógicas),
http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a
0080087da4.html
“Configuraciones adicionales de RIPv1.”
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.
Haga clic en Pings de R2 en la figura.
Este resultado muestra a 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.
Usted ya sabe que 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 Inter-Domain Routing
(CIDR). Sin embargo, ¿podría haber espacio para expandir el formato de mensaje del RIPv1 a fin de
poder incluir la máscara de subred para que verdaderamente podamos tener una configuración de red no
contigua? ¿Cómo cambiaría el formato de este mensaje en la figura para incluir la máscara de subred?
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.
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.
Como vimos con las actualizaciones 172.30.0.0/16 a R2 de R1 y R3, RIPv1 resume las subredes hacia el
borde con clase o usa la máscara de subred de la interfaz saliente para determinar qué subredes publicar.
Versión 2
En forma predeterminada, cuando un proceso de RIP se encuentra configurado en un router Cisco, éste
ejecuta RIPv1. Sin embargo, a pesar de que el router sólo envía mensajes de RIPv1, puede interpretar los
mensajes de RIPv1 y RIPv2. Un router de RIPv1 simplemente ignorará los campos de RIPv2 en la
entrada de ruta.
máscara de subred en todas las actualizaciones, lo que hará que RIPv2 sea un protocolo de enrutamiento
sin clase.
“Resumen automático.”
ú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.
Versión.
Un buen lugar para comenzar la resolución de problemas en una red que está ejecutando RIP es verificar
que la versión 2 esté configurada en todos los routers. A pesar de que RIPv1 y RIPv2 son compatibles,
RIPv1 no admite subredes no contiguas, VLSM ni rutas de superred CIDR. Siempre es mejor usar el
mismo protocolo de enrutamiento en todos los routers a menos que exista una razón específica para no
hacerlo.
Sentencias de red.
Otra fuente de problemas pueden ser las sentencias de red incorrectas o faltantes. Recuerde que la
sentencia de red hace dos cosas:
Le permite al protocolo de enrutamiento enviar y recibir actualizaciones en cualquier interfaz
local que pertenezca a esa red.
Incluye esa red en sus actualizaciones de enrutamiento a los routers vecinos.
Una sentencia de red incorrecta o faltante ocasionará la pérdida de actualizaciones de enrutamiento y
provocará que las actualizaciones de enrutamiento no se envíen o no se reciban en una interfaz.
Resumen automático.
Si necesita o desea enviar subredes específicas y no simplemente rutas resumidas, asegúrese de que el
resumen automático esté desactivado.
7.4.3 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 IS-IS 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 fuente 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.
Por ejemplo, en la figura, R1 está propagando una ruta por defecto a todos los otros routers de este
dominio de enrutamiento. Sin embargo, alguien ha agregado por error el router R4 a la red, lo que
también propaga una ruta por defecto. Algunos routers pueden reenviar tráfico predeterminado a R4 en
lugar de hacia el verdadero router de gateway, R1. Estos paquetes pueden "perderse" y no verse nunca
más.
Resumen.
RIPv2 es un protocolo de enrutamiento por vector de distancia sin clase, que se define en RFC 1723.
Debido a que RIPv2 es un protocolo de enrutamiento sin clase, incluye la máscara de subred con las
direcciones de red en las actualizaciones de enrutamiento. Como otros protocolos de enrutamiento sin
clase, RIPv2 admite superredes CIDR, VLSM y redes no contiguas.
Vimos que los protocolos de enrutamiento con clase como RIPv1 no pueden admitir redes no contiguas
porque resumen automáticamente en los bordes de las redes principales. Un router que recibe
actualizaciones de enrutamiento de varios routers que publican la misma ruta resumida con clase no
pueden determinar qué subredes pertenecen a qué ruta resumida. Esta incapacidad provoca resultados
inesperados, tales como paquetes con un enrutamiento incorrecto.
La versión predeterminada de RIP es la versión 1. El comando version 2 se usa para cambiar RIP a
RIPv2.
De similar forma que RIPv1, RIPv2 resume automáticamente en los bordes de las redes principales. Sin
embargo, con RIPv2, el resumen automático puede desactivarse con el comando no auto-summary. El
resumen automático debe deshabilitarse para admitir las redes no contiguas. RIPv2 también admite
superredes CIDR y VLSM porque la máscara de subred específica está incluida con la dirección de red en
todas las actualizaciones de enrutamiento. Puede usar el comando debug ip rip para ver la actualización
RIP que envía la máscara de subred con la dirección de red como parte de la entrada de ruta.
El comando show ip protocols mostrará que RIP envía y recibe actualizaciones de la versión 2 y también
mostrará si el resumen automático tiene efecto.