Gedrag van RIP en IGRP bij het verzenden en ontvangen van updates

Inleiding

Dit document verklaart de reeks acties die door zowel Routing Information Protocol (RIP) als Interior Gateway Routing Protocol (IGRP) zijn ondernomen wanneer zij de routingupdates verzenden of ontvangen.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is van toepassing op deze software- en hardwareversies:

• Cisco IOS-softwarerelease 12.2(27)XR

• Cisco 2500 Series routers

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Algemeen gedrag

Verzend updates

Wanneer RIP of IGRP een update verzenden, voeren zij bepaalde controles uit voordat zij de update bekendmaken. Deze lijst toont de opeenvolging van gebeurtenissen die vóór Router 1 updates naar Router 2 stuurt. Het netwerkdiagram staat u toe om de opeenvolging van gebeurtenissen nauwer te onderzoeken.

• Is het subnetinformatie deel van het zelfde grote net zoals de interface die de update bronnen?

  • Nee: Router 1 vat samen aan de belangrijkste netto grens en adverteert het netwerk.

  • Ja: Heeft het netwerk hetzelfde subnetmasker als de interface die de update bronnen?

    • Ja: Router 1 adverteert het net.

    • Nee: Heeft het netwerk een /32 masker?

      • Ja: Als het RIP is, dan wordt het netwerk geadverteerd. Als het IGRP is, laat router 1 het netwerk vallen.

      • Nee: Router 1 laat het netwerk vallen.

Ontvang updates

Wanneer RIP of IGRP een update ontvangt, voeren zij bepaalde controles uit alvorens zij de update aanvaarden en het subnetmasker toepassen. Dit is de opeenvolging van gebeurtenissen die voorvallen alvorens Router 2 een update van Router 1 accepteert:

• Is het subsysteem ontvangen in de update op het zelfde grote net als de interface die de update ontving?

  • Ja: Router 2 past het masker van de interface toe die de update ontving. Als het geadverteerde netwerk een host bit heeft dat in het host gedeelte van de update is ingesteld, past Router 2 het host-masker (/32) toe. In het geval van het RIP blijft het de route /32 naar de volgende router adverteren, maar IGRP niet.

  • Nee: Bestaan er al subnetten van dit belangrijke net in de routingtabel, bekend van interfaces anders dan die die de update ontvangen hebben? Het netwerk in deze update zou een belangrijk net moeten zijn tenzij het verband tussen de twee routers een ongenummerde verbinding is, in welk geval het voor de update mogelijk is om baanbrekende informatie te bevatten.

    • Ja: Router 2 negeert de update.

    • Nee: Router 2 past een klasbaar masker toe. Als de update over een ongenummerde verbinding kwam en Subnet informatie bevat (bits in netto gedeelte van netwerk worden ingesteld), dan past Router 2 een Host masker toe. Raadpleeg het gedeelte Ongenummerde opdracht begrijpen en configureren voor ongenummerde voorbeelden.

Specifieke zaak

Verzend updates

Wanneer router 1 een update naar router 2 stuurt, voert het deze controles uit:

• Is 131.108.5.0/24 deel van hetzelfde belangrijke net als 131.108.2.0/24, welke bronnen voor de actualisering?

  • Ja: Heeft 131.108.5.0/24 hetzelfde subnetmasker als 131.108.2.0/24, welke bronnen de update?

    • Ja: Router 1 adverteert het netwerk.

• Is 137.99.88.0/24 deel van hetzelfde belangrijke net als 131.108.2.0/24, welke bronnen voor de actualisering?

  • Nee: router 1 vat 137.99.88.0/24 samen op de belangrijkste netto grens en adverteert de route als 137.99.0.0.

Dit proces leidt tot router 1 met 131.108.5.0 en 137.99.0.0 in zijn update tot router 2. U kunt dit in de uitvoer van het debug ip van de rip op router 1 zien:

*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

Ontvang updates

Wanneer u het debug ip bevel uitgeeft, kunt u de Routing update zien die op Router 2 van router 1 wordt ontvangen:

*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

Kijk naar de controles router 2 uitvoert om te bepalen welk masker op een ontvangen netwerk van toepassing is.

• Is de ontvangen grote netto 137.99.0.0 gelijk aan 131.108.2.0, het adres dat is toegewezen aan de interface die de update ontving?

  • Nee: Bestaan er al subnetten van dit belangrijke net in de routingtabel die van andere interfaces bekend is?

    • Nee: Router 2 past het natuurlijke masker (/16) toe omdat 137.99.0.0 een klasse B-adres is.

• Behoort Subnet 131.108.5.0 tot het zelfde grote net zoals Subnet 131.108.2.0, wat de interface is die de update ontving?

  • Ja: Router 2 past het masker/24 toe, dat het masker van de interface is dat de update ontving.

Dit proces resulteert in deze netwerken en maskers in de routing tabel van router 2, die met de opdracht tonen IP-route wordt weergegeven:

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

Gerelateerde informatie

• Waarom steunen RIPv1 en IGRP Subnetmasker met variabele lengte niet?
• Waarom worden geen netwerken die overeenkomen met RIP of IGRP?
• IGRP-ondersteuningspagina voor technologie
• RIP pagina voor technologieondersteuning
• Ondersteuning van IP-routingprotocollen voor technologie
• Technische ondersteuning en documentatie – Cisco Systems