IP : Protocolos de routing de IP

Comportamiento de RIP y IGRP al enviar y recibiendo las actualizaciones

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento explica la serie de acciones que realizan los protocolos Routing Information Protocol (RIP) e Interior Gateway Routing Protocol (IGRP) al enviar o recibir actualizaciones de ruteo.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información en este documento se aplica a estas versiones de software y hardware:

  • Cisco IOS Software Release 12.2(27)

  • Cisco 2500 Series Routers

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Comportamiento general

Envíe actualizaciones

Cuando el RIP o el IGRP envía una actualización, realizan ciertos controles antes de que hagan publicidad de la actualización. Esta lista muestra la Secuencia de eventos que ocurre antes de que el router1 envíe las actualizaciones al router2. El diagrama de la red permite que usted examine la Secuencia de eventos más de cerca.

  • ¿Es la parte de la información de subred la misma red principal que la interfaz esa las fuentes la actualización?

    • No: El Router 1 condensa en un límite de red principal y anuncia la red.

    • Sí: ¿La red tiene la misma máscara de subred que la interfaz esa las fuentes la actualización?

      • Sí: El router 1 anuncia la subred.

      • No: ¿La red tiene una máscara de /32?

        • Sí: Si es RIP, después se hace publicidad la red. Si es IGRP, entonces el router1 cae la red.

        • No: El router1 cae la red.

‘Recibir actualizaciones’

Cuando el RIP o el IGRP recibe una actualización, realizan ciertos controles antes de que validen la actualización y apliquen a la máscara de subred. Ésta es la Secuencia de eventos que ocurre antes de que el router2 valide una actualización del router1:

  • ¿Se recibe la subred en la actualización en la misma red principal que la interfaz que recibió la actualización?

    • Sí: El Router 2 aplica la máscara de la interfaz que recibió la actualización. Si el red que recibe un anuncio tiene un conjunto de bits del host en la porción del host de la actualización, el router2 aplica la máscara del host (/32). En el caso de RIP, éste continua para anunciar la /32 route al router subsiguiente, pero IGRP no lo hace.

    • No: ¿Hay alguna subred de esta red principal en la tabla de ruteo, proveniente de una interfaz distinta de aquella que recibió la actualización? La red en esta actualización debe ser una red principal a menos que el link entre el dos Routers sea un link sin numerar, en este caso es posible que la actualización contenga la información de subred.

      • Sí: El router2 ignora la actualización.

      • No: El Router 2 aplica una máscara con clase. Si la actualización se encuentra con un link sin numeración y contiene información de subred (se establecen bits en la porción de subred de la red), el Router 2 aplica una máscara de host. Refiera a entender y a configurar el comando ip unnumbered para los ejemplos de caso innumerables.

http://www.cisco.com/c/dam/en/us/support/docs/ip/ip-routed-protocols/13723-54a.gif

Caso específico

Envíe actualizaciones

Cuando el Router 1 envía una actualización al Router 2, éste verifica lo siguiente:

  • ¿Es 131.108.5.0/24 partes de la misma red principal que 131.108.2.0/24, que las fuentes la actualización?

    • Sí: ¿131.108.5.0/24 tiene la misma máscara de subred que 131.108.2.0/24, que las fuentes la actualización?

      • Sí: El router 1 anuncia la red.

  • ¿Es 137.99.88.0/24 partes de la misma red principal que 131.108.2.0/24, que las fuentes la actualización?

    • No: El router1 resume 137.99.88.0/24 en el límite de red principal y hace publicidad de la ruta como 137.99.0.0.

Este resultados del proceso en el router1 incluyendo 131.108.5.0 y 137.99.0.0 en su actualización al router2. Usted puede ver esto en el comando debug ip rip hecho salir mostrado en el router1:

*Mar 25 00:22:46.177: RIP: sending v1 update to 255.255.255.255 via Serial0 (131.108.2.2)  
*Mar 25 00:22:46.178: RIP: build update entries
*Mar 25 00:22:46.182: subnet 131.108.5.0, metric 1
*Mar 25 00:22:46.185: network 137.99.0.0, metric 1

‘Recibir actualizaciones’

Cuando usted publica el comando debug ip rip, usted puede ver la actualización de ruteo recibida en el router2 del router1:

*Mar 25 00:22:46.201: RIP: received v1 update from 131.108.2.2 on Serial0 
*Mar 25 00:22:46.203:131.108.5.0 in 1 hops
*Mar 25 00:22:46.205:137.99.0.0 in 1 hops

Mire los controles que el router2 se realiza para determinar qué máscara a aplicarse en una red recibida.

  • ¿Es la red principal recibida 137.99.0.0 igual a 131.108.2.0 que es la dirección asignada a la interfaz que ha recibido la actualización?

    • No: ¿Subredes de esta red principal existen ya en la tabla de ruteo sabida de otras interfaces?

      • No: El router2 aplica a la máscara natural (/16) porque 137.99.0.0 es un direccionamiento de la clase B.

  • ¿Pertenece la subred 131.108.5.0 a la misma red principal con una subred 131.108.2.0 que es la interfaz que recibe la actualización?

    • Sí: Router 2 aplica la máscara /24, que es la máscara de la interfaz que recibió la actualización.

Este resultados del proceso en estas redes y máscaras en la tabla de ruteo de router2, visualizada con el comando show ip route:

R    137.99.0.0/16 [120/1] via 131.108.2.2, 00:00:07, Serial0 
     131.108.0.0/24 is subnetted, 3 subnets
R    131.108.5.0 [120/1] via 131.108.2.2, 00:00:08, Serial0 
C    131.108.2.0 is directly connected, Serial0
C    131.108.3.0 is directly connected, Ethernet0

Información Relacionada


Document ID: 13723