Routing Information Protocol - Versionsgeschichte

Uweschwoebel: /* Siehe auch */ strukturiert und reduziert, die Einträge sind bereits im Artikeltext verlinkt

2024-02-26T21:30:32Z

Siehe auch: strukturiert und reduziert, die Einträge sind bereits im Artikeltext verlinkt

← Nächstältere Version		Version vom 26. Februar 2024, 23:30 Uhr
Zeile 153:		Zeile 153:

	== Siehe auch ==		== Siehe auch ==
			* [[Interior Gateway Routing Protocol]] (IGRP)
	[[Open Shortest Path First\|OSPF]], [[Interior Gateway Routing Protocol\|IGRP]], [[Enhanced Interior Gateway Routing Protocol\|EIGRP]], [[Border Gateway Protocol\|BGP]], [[IS-IS]], [[Bidirectional Forwarding Detection\|BFD]]
			* [[Enhanced Interior Gateway Routing Protocol]] (EIGRP)
			* [[Border Gateway Protocol]] (BGP)

	== Weblinks ==		== Weblinks ==

Crazy1880: Vorlagen-fix (RFC-Internet)

2023-07-31T18:33:17Z

Vorlagen-fix (RFC-Internet)

← Nächstältere Version		Version vom 31. Juli 2023, 20:33 Uhr
Zeile 3:		Zeile 3:
	Es gehört zur Klasse der [[Interior Gateway Protocol]]s (IGP).		Es gehört zur Klasse der [[Interior Gateway Protocol]]s (IGP).

	RIP wurde zuerst in RFC 1058 (1988) definiert. Das Protokoll wurde seitdem mehrfach erweitert und liegt nun als RIP Version 2 (RFC 2453) vor.		RIP wurde zuerst in <nowiki>RFC 1058</nowiki> (1988) definiert. Das Protokoll wurde seitdem mehrfach erweitert und liegt nun als RIP Version 2 (<nowiki>RFC 2453</nowiki>) vor.

	Beide Versionen werden noch heute eingesetzt, jedoch werden sie als technisch veraltet betrachtet und sind durch neuere Protokolle wie [[Open Shortest Path First]] (OSPF) oder das [[Open Systems Interconnection\|OSI]] Protokoll [[IS-IS]] abgelöst worden.		Beide Versionen werden noch heute eingesetzt, jedoch werden sie als technisch veraltet betrachtet und sind durch neuere Protokolle wie [[Open Shortest Path First]] (OSPF) oder das [[Open Systems Interconnection\|OSI]] Protokoll [[IS-IS]] abgelöst worden.

	RIP wird in den Protokollen [[Internet Protocol\|IP]] und [[Internetwork Packet Exchange\|IPX]] benutzt und wurde unter dem Namen		RIP wird in den Protokollen [[Internet Protocol\|IP]] und [[Internetwork Packet Exchange\|IPX]] benutzt und wurde unter dem Namen
	RIPng (RIP next generation) im RFC 2080 (1997) erweitert, um auch IPv6 zu unterstützen.		RIPng (RIP next generation) im <nowiki>RFC 2080</nowiki> (1997) erweitert, um auch IPv6 zu unterstützen.

	== Überblick ==		== Überblick ==
Zeile 53:		Zeile 53:

	=== RIPv1 ===		=== RIPv1 ===
	Die ursprüngliche Spezifikation von RIP in RFC 1058 benutzt noch kein [[Classless Inter-Domain Routing\|CIDR]]. Die regelmäßig versendeten Routinginformationen enthalten keine Informationen über die verwendeten Subnetze, so dass alle Netze die Größe der zugehörigen Netzklasse haben müssen. Des Weiteren ist in RIPv1 keine Möglichkeit zur Authentifizierung vorgesehen, so dass verschiedene Angriffe auf das Routing eines Netzes erfolgen können. RIPv1 begrenzt zudem die Anzahl der möglichen HOPs zwischen Routern auf 15.		Die ursprüngliche Spezifikation von RIP in <nowiki>RFC 1058</nowiki> benutzt noch kein [[Classless Inter-Domain Routing\|CIDR]]. Die regelmäßig versendeten Routinginformationen enthalten keine Informationen über die verwendeten Subnetze, so dass alle Netze die Größe der zugehörigen Netzklasse haben müssen. Des Weiteren ist in RIPv1 keine Möglichkeit zur Authentifizierung vorgesehen, so dass verschiedene Angriffe auf das Routing eines Netzes erfolgen können. RIPv1 begrenzt zudem die Anzahl der möglichen HOPs zwischen Routern auf 15.

	=== RIPv2 ===		=== RIPv2 ===
Zeile 61:		Zeile 61:
	=== RIPng ===		=== RIPng ===

	'''RIPng''' ist in RFC 2080 definiert und enthält Erweiterungen zur Unterstützung von [[IPv6]].		'''RIPng''' ist in <nowiki>RFC 2080</nowiki> definiert und enthält Erweiterungen zur Unterstützung von [[IPv6]].

	== Paketformate ==		== Paketformate ==
Zeile 121:		Zeile 121:
	Die Tabellen sind 4 Bytes breit.		Die Tabellen sind 4 Bytes breit.

	Abhängig vom Eintrag im Feld ''version'' besteht ein ''RIP-Eintrag'' aus einem RIPv1-Eintrag (''AFI'' etc.), einem RIPv2-Eintrag (s. u.) oder einem Authentifizierungs-Eintrag (s. u.). Mehr Details stehen in RFC 2453.		Abhängig vom Eintrag im Feld ''version'' besteht ein ''RIP-Eintrag'' aus einem RIPv1-Eintrag (''AFI'' etc.), einem RIPv2-Eintrag (s. u.) oder einem Authentifizierungs-Eintrag (s. u.). Mehr Details stehen in <nowiki>RFC 2453</nowiki>.

	==== Beispiele eines RIP-Eintrags ====		==== Beispiele eines RIP-Eintrags ====
Zeile 156:		Zeile 156:

	== Weblinks ==		== Weblinks ==
	* RFC ~~1058~~ – Routing Information Protocol		* {{RFC-Internet \|Autor=C. Hedrick \|RFC=1058 \|Titel=Routing Information Protocol \|Datum=1988-06}}
	* RFC ~~2453~~ – RIP Version 2		* {{RFC-Internet \|Autor=G. Malkin \|RFC=2453 \|Titel=RIP Version 2 \|Datum=1988-11}}
	* RFC ~~2080~~ – RIPng for IPv6		* {{RFC-Internet \|Autor=G. Malkin, R. Minnear \|RFC=2080 \|Titel=RIPng for IPv6 \|Datum=1997-01}}
	* [https://folk.universitetetioslo.no/michawe/research/tools/irvtool/index.html irvtool] – ein RIP-/OSPF-Visualisierungstool (Java/GPL)		* [https://folk.universitetetioslo.no/michawe/research/tools/irvtool/index.html irvtool] – ein RIP-/OSPF-Visualisierungstool (Java/GPL)

Haraldmmueller: /* Beispiel */ dt.

2021-10-05T11:04:25Z

Beispiel: dt.

← Nächstältere Version		Version vom 5. Oktober 2021, 13:04 Uhr
Zeile 33:		Zeile 33:
	* Router C mit Hop 2 über Router B und Router A.		* Router C mit Hop 2 über Router B und Router A.

	Fällt Router A aus, teilt Router B beim nächsten periodischen Update an Router C den Hopcount 16 mit: ~~Infinität~~ ~~(nicht~~ ~~Erreichbarkeit)~~.		Fällt Router A aus, teilt Router B beim nächsten periodischen Update an Router C den Hopcount 16 mit, was Nichterreichbarkeit oder "unendliche Route" bedeutet.
	Trifft nun bei Router B ein Paket eines anderen Routers ein, der Netz 1 noch erreichen kann, ist dessen Hopcount geringer und Router B wird seine Routingtabelle entsprechend aktualisieren.		Trifft nun bei Router B ein Paket eines anderen Routers ein, der Netz 1 noch erreichen kann, ist dessen Hopcount geringer und Router B wird seine Routingtabelle entsprechend aktualisieren.

	=== Problemfälle ===		=== Problemfälle ===

	Ist Netz 1 ausgefallen und sendet Router C seine Routingtabelle an Router B bevor die Nachricht von der Nicht-Erreichbarkeit des Netzes durch das Netz propagiert wurde, erhält Router B nach dem Update von Router A die Information, das Netz 1 noch über Router C mit Hopcount 3 erreichen zu können. Router C hat seine Routingtabelle ja noch nicht aktualisiert und sendet diese veraltete Information weiterhin an seine Nachbarn, bis er von dort den Hopcount 16 erfährt. Damit übernimmt Router B dann die Route in das Netz 1 mit Hopcount 4.		Ist Netz 1 ausgefallen und sendet Router C seine Routingtabelle an Router B, bevor die Nachricht von der Nicht-Erreichbarkeit des Netzes durch das Netz propagiert wurde, erhält Router B nach dem Update von Router A die Information, das Netz 1 noch über Router C mit Hopcount 3 erreichen zu können. Router C hat seine Routingtabelle ja noch nicht aktualisiert und sendet diese veraltete Information weiterhin an seine Nachbarn, bis er von dort den Hopcount 16 erfährt. Damit übernimmt Router B dann die Route in das Netz 1 mit Hopcount 4.

	Router B würde beim nächsten Austausch Hop 4 an Router C senden, dieser übernimmt diese Information und trägt Hop 5 in seine Routingtabelle ein, da er bisher bereits Netz 1 über Router B erreicht. Somit schaukeln sich beide Router nach und nach bis auf Hop 16 auf – ~~mit~~ ~~der~~ ~~entsprechenden~~ ~~Zeitlichen Verzögerung bis~~ ~~zur~~ ~~Konvergenz~~.		Router B würde beim nächsten Austausch Hop 4 an Router C senden, dieser übernimmt diese Information und trägt Hop 5 in seine Routingtabelle ein, da er bisher bereits Netz 1 über Router B erreicht. Somit schaukeln sich beide Router nur langsam nach und nach bis auf Hop 16 auf, bis von allen Beteiligten Nichterreichbarkeit festgestellt wird.

	Mechanismen zur Vermeidung spezieller Fälle dieses Problems sind [[Split Horizon]], [[Triggered Updates]] und (bei RIP mit IP) [[Split Horizon\|Split Horizon with Poisoned Reverse]]. Mit dem Erweiterungsalgorithmus RIP-MTI lassen sich Routing-Loops sogar vollständig erkennen und das Count-to-Infinity Problem tritt überhaupt nicht mehr auf.		Mechanismen zur Vermeidung spezieller Fälle dieses Problems sind [[Split Horizon]], [[Triggered Updates]] und (bei RIP mit IP) [[Split Horizon\|Split Horizon with Poisoned Reverse]]. Mit dem Erweiterungsalgorithmus RIP-MTI lassen sich Routing-Loops sogar vollständig erkennen und das Count-to-Infinity-Problem tritt überhaupt nicht mehr auf.

	RIP erlaubt deshalb nur Netze mit einer maximalen Länge von 15 Routern (d. h. der längste Pfad darf maximal über 15 Router gehen). ~~Außerdem~~ hat es je nach Version noch weitere Nachteile: Lange Konvergenzzeit, nur kleine bis mittlere Netze, Flutung des Netzes durch Austausch der Routingtabellen bei RIPv1 (alle 30 Sekunden bei IP, alle 60 Sekunden bei IPX) über [[Broadcast]], keine [[Subnetz]]-Unterstützung und keine Authentifizierung. RIP wird mehr und mehr von [[Open Shortest Path First\|OSPF]] abgelöst.		RIP erlaubt deshalb nur Netze mit einer maximalen Länge von 15 Routern (d. h. der längste Pfad darf maximal über 15 Router gehen). Daneben hat RIP je nach Version noch weitere Nachteile: Lange Konvergenzzeit, nur kleine bis mittlere Netze, Flutung des Netzes durch Austausch der Routingtabellen bei RIPv1 (alle 30 Sekunden bei IP, alle 60 Sekunden bei IPX) über [[Broadcast]], keine [[Subnetz]]-Unterstützung und keine Authentifizierung. RIP wird daher mehr und mehr von [[Open Shortest Path First\|OSPF]] abgelöst.

	== Versionen ==		== Versionen ==

Aka: /* Weblinks */ https

2021-07-29T17:26:52Z

Weblinks: https

← Nächstältere Version		Version vom 29. Juli 2021, 19:26 Uhr
Zeile 159:		Zeile 159:
	* RFC 2453 – RIP Version 2		* RFC 2453 – RIP Version 2
	* RFC 2080 – RIPng for IPv6		* RFC 2080 – RIPng for IPv6
	* [~~http~~://~~heim~~.~~ifi.uio~~.no/michawe/research/tools/irvtool/index.html irvtool] – ein RIP-/OSPF-Visualisierungstool (Java/GPL)		* [https://folk.universitetetioslo.no/michawe/research/tools/irvtool/index.html irvtool] – ein RIP-/OSPF-Visualisierungstool (Java/GPL)

	[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]		[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]

ExtremPilotHD: Weiterleitung aufgelöst

2020-06-08T18:22:13Z

Weiterleitung aufgelöst

← Nächstältere Version		Version vom 8. Juni 2020, 20:22 Uhr
Zeile 18:		Zeile 18:
	Um Änderungen im Netzwerk (Ausfall oder Start eines Routers) zu erkennen, wird das Senden der Routingtabellen – das sogenannte ''Advertisement'' – regelmäßig (alle 30 Sekunden bei IP) wiederholt, dabei wird stets die gesamte Routingtabelle jedoch nur an alle direkten Nachbarn gesendet. Die Routinginformationen breiten sich damit relativ langsam im Netz aus, bei einer maximalen Ausdehnung des Netzes von 15 Routern ("Hops") beträgt die Zeitdauer bereits sieben Minuten. Zudem ist nicht garantiert, dass die Informationen bei den benachbarten Routern ankommen, da die Advertisements über [[User Datagram Protocol\|UDP]] versendet werden, die Übertragung also nicht zuverlässig ist.		Um Änderungen im Netzwerk (Ausfall oder Start eines Routers) zu erkennen, wird das Senden der Routingtabellen – das sogenannte ''Advertisement'' – regelmäßig (alle 30 Sekunden bei IP) wiederholt, dabei wird stets die gesamte Routingtabelle jedoch nur an alle direkten Nachbarn gesendet. Die Routinginformationen breiten sich damit relativ langsam im Netz aus, bei einer maximalen Ausdehnung des Netzes von 15 Routern ("Hops") beträgt die Zeitdauer bereits sieben Minuten. Zudem ist nicht garantiert, dass die Informationen bei den benachbarten Routern ankommen, da die Advertisements über [[User Datagram Protocol\|UDP]] versendet werden, die Übertragung also nicht zuverlässig ist.

	Die Kosten (auch ''Metrik'') bezeichnen den Aufwand, um ein bestimmtes Netz zu erreichen. Beim Protokoll RIP wird zur Berechnung der Metrik allein der [[Hop Count]] verwendet; er bezeichnet die Anzahl der Router, die entlang eines Pfades bis zum Zielnetz durchlaufen werden müssen. Im Gegensatz zu anderen Routing-Protokollen lässt RIP damit die Bandbreite mehrerer zur Auswahl stehender Wege unberücksichtigt. Bei RIP für IPX wird zusätzlich noch der Tick-Count benutzt; er bezeichnet die Verzögerung eines Paketes durch alle Router bis zum Zielnetz.		Die Kosten (auch ''Metrik'') bezeichnen den Aufwand, um ein bestimmtes Netz zu erreichen. Beim Protokoll RIP wird zur Berechnung der Metrik allein der [[Hop (Netzwerktechnologie)\|Hop Count]] verwendet; er bezeichnet die Anzahl der Router, die entlang eines Pfades bis zum Zielnetz durchlaufen werden müssen. Im Gegensatz zu anderen Routing-Protokollen lässt RIP damit die Bandbreite mehrerer zur Auswahl stehender Wege unberücksichtigt. Bei RIP für IPX wird zusätzlich noch der Tick-Count benutzt; er bezeichnet die Verzögerung eines Paketes durch alle Router bis zum Zielnetz.

	Im Gegensatz zu [[Open Shortest Path First\|OSPF]] und [[NetWare Link-Services Protocol\|NLSP]] kennt ein RIP-Router immer nur seine direkten Nachbarn. Bei Änderungen im Netzwerk dauert es eine gewisse Zeit, bis alle Router wieder eine einheitliche Sicht auf das Netzwerk haben. Mit Erreichen dieses Zustandes spricht man von [[Konvergenz (Netzwerk)\|Konvergenz]]. Durch Nutzung des [[Bidirectional Forwarding Detection\|BFD]]-Protokolls durch RIP lassen sich Konvergenzzeiten im Millisekundenbereich erzielen.		Im Gegensatz zu [[Open Shortest Path First\|OSPF]] und [[NetWare Link-Services Protocol\|NLSP]] kennt ein RIP-Router immer nur seine direkten Nachbarn. Bei Änderungen im Netzwerk dauert es eine gewisse Zeit, bis alle Router wieder eine einheitliche Sicht auf das Netzwerk haben. Mit Erreichen dieses Zustandes spricht man von [[Konvergenz (Netzwerk)\|Konvergenz]]. Durch Nutzung des [[Bidirectional Forwarding Detection\|BFD]]-Protokolls durch RIP lassen sich Konvergenzzeiten im Millisekundenbereich erzielen.

Invisigoth67: typo

2019-05-05T12:19:50Z

typo

← Nächstältere Version		Version vom 5. Mai 2019, 14:19 Uhr
Zeile 121:		Zeile 121:
	Die Tabellen sind 4 Bytes breit.		Die Tabellen sind 4 Bytes breit.

	Abhängig vom Eintrag im Feld ''version'' besteht ein ''RIP-Eintrag'' aus einem RIPv1-Eintrag (''AFI'' etc), einem RIPv2-Eintrag (s. u.) oder einem Authentifizierungs-Eintrag (s. u.). Mehr Details stehen in RFC 2453.		Abhängig vom Eintrag im Feld ''version'' besteht ein ''RIP-Eintrag'' aus einem RIPv1-Eintrag (''AFI'' etc.), einem RIPv2-Eintrag (s. u.) oder einem Authentifizierungs-Eintrag (s. u.). Mehr Details stehen in RFC 2453.

	==== Beispiele eines RIP-Eintrags ====		==== Beispiele eines RIP-Eintrags ====

194.208.36.118: /* Überblick */

2019-03-14T10:09:36Z

Überblick

← Nächstältere Version		Version vom 14. März 2019, 12:09 Uhr
Zeile 16:		Zeile 16:
	RIPv1 kennt keine Subnetzinformationen. Ein Router kann daher Subnetze nur auf zwei Wegen berücksichtigen: entweder er nutzt die an seinem Interface speziell konfigurierte Subnetzmaske oder er zieht die Standardsubnetzmaske heran. Auf Grund dieser Einschränkung können über RIPv1 verwaltete Netze nicht [[Variable Length Subnet Mask\|VLSM]] oder verteilte Subnetze berücksichtigen.		RIPv1 kennt keine Subnetzinformationen. Ein Router kann daher Subnetze nur auf zwei Wegen berücksichtigen: entweder er nutzt die an seinem Interface speziell konfigurierte Subnetzmaske oder er zieht die Standardsubnetzmaske heran. Auf Grund dieser Einschränkung können über RIPv1 verwaltete Netze nicht [[Variable Length Subnet Mask\|VLSM]] oder verteilte Subnetze berücksichtigen.

	Um Änderungen im Netzwerk (Ausfall oder Start eines Routers) zu erkennen, wird das Senden der Routingtabellen – das sogenannte ''Advertisement'' – regelmäßig (alle 30 Sekunden bei IP) wiederholt, dabei wird stets die gesamte Routingtabelle jedoch nur an alle direkten Nachbarn gesendet. Die Routinginformationen breiten sich damit relativ langsam im Netz aus, bei einer maximalen Ausdehnung des Netzes von 15 Routern ("Hops") beträgt ~~sie~~ bereits sieben Minuten. Zudem ist nicht garantiert, dass die Informationen bei den benachbarten Routern ankommen, da die Advertisements über [[User Datagram Protocol\|UDP]] versendet werden, die Übertragung also nicht zuverlässig ist.		Um Änderungen im Netzwerk (Ausfall oder Start eines Routers) zu erkennen, wird das Senden der Routingtabellen – das sogenannte ''Advertisement'' – regelmäßig (alle 30 Sekunden bei IP) wiederholt, dabei wird stets die gesamte Routingtabelle jedoch nur an alle direkten Nachbarn gesendet. Die Routinginformationen breiten sich damit relativ langsam im Netz aus, bei einer maximalen Ausdehnung des Netzes von 15 Routern ("Hops") beträgt die Zeitdauer bereits sieben Minuten. Zudem ist nicht garantiert, dass die Informationen bei den benachbarten Routern ankommen, da die Advertisements über [[User Datagram Protocol\|UDP]] versendet werden, die Übertragung also nicht zuverlässig ist.

	Die Kosten (auch ''Metrik'') bezeichnen den Aufwand, um ein bestimmtes Netz zu erreichen. Beim Protokoll RIP wird zur Berechnung der Metrik allein der [[Hop Count]] verwendet; er bezeichnet die Anzahl der Router, die entlang eines Pfades bis zum Zielnetz durchlaufen werden müssen. Im Gegensatz zu anderen Routing-Protokollen lässt RIP damit die Bandbreite mehrerer zur Auswahl stehender Wege unberücksichtigt. Bei RIP für IPX wird zusätzlich noch der Tick-Count benutzt; er bezeichnet die Verzögerung eines Paketes durch alle Router bis zum Zielnetz.		Die Kosten (auch ''Metrik'') bezeichnen den Aufwand, um ein bestimmtes Netz zu erreichen. Beim Protokoll RIP wird zur Berechnung der Metrik allein der [[Hop Count]] verwendet; er bezeichnet die Anzahl der Router, die entlang eines Pfades bis zum Zielnetz durchlaufen werden müssen. Im Gegensatz zu anderen Routing-Protokollen lässt RIP damit die Bandbreite mehrerer zur Auswahl stehender Wege unberücksichtigt. Bei RIP für IPX wird zusätzlich noch der Tick-Count benutzt; er bezeichnet die Verzögerung eines Paketes durch alle Router bis zum Zielnetz.

Schnabeltassentier: Änderungen von 109.192.22.208 (Diskussion) auf die letzte Version von Invisigoth67 zurückgesetzt

2018-10-25T12:50:27Z

Änderungen von 109.192.22.208 (Diskussion) auf die letzte Version von Invisigoth67 zurückgesetzt

@@ Zeile 8: / Zeile 8: @@
 RIP wird in den Protokollen [[Internet Protocol|IP]] und [[Internetwork Packet Exchange|IPX]] benutzt und wurde unter dem Namen
-RIPng (RIP next generation) im RFC 2080 (1997) erweitert,
+RIPng (RIP next generation) im RFC 2080 (1997) erweitert, um auch IPv6 zu unterstützen.
 ==== Beispiele eines RIP-Eintrags ====

109.192.22.208: /* Beispiel */

2018-10-25T12:50:01Z

Beispiel

@@ Zeile 8: / Zeile 8: @@
 RIP wird in den Protokollen [[Internet Protocol|IP]] und [[Internetwork Packet Exchange|IPX]] benutzt und wurde unter dem Namen
-RIPng (RIP next generation) im RFC 2080 (1997) erweitert, um auch IPv6 zu unterstützen.
+RIPng (RIP next generation) im RFC 2080 (1997) erweitert,
 ==== Beispiele eines RIP-Eintrags ====

Invisigoth67: form

2018-09-08T20:44:28Z

form

← Nächstältere Version		Version vom 8. September 2018, 22:44 Uhr
Zeile 40:		Zeile 40:
	Ist Netz 1 ausgefallen und sendet Router C seine Routingtabelle an Router B bevor die Nachricht von der Nicht-Erreichbarkeit des Netzes durch das Netz propagiert wurde, erhält Router B nach dem Update von Router A die Information, das Netz 1 noch über Router C mit Hopcount 3 erreichen zu können. Router C hat seine Routingtabelle ja noch nicht aktualisiert und sendet diese veraltete Information weiterhin an seine Nachbarn, bis er von dort den Hopcount 16 erfährt. Damit übernimmt Router B dann die Route in das Netz 1 mit Hopcount 4.		Ist Netz 1 ausgefallen und sendet Router C seine Routingtabelle an Router B bevor die Nachricht von der Nicht-Erreichbarkeit des Netzes durch das Netz propagiert wurde, erhält Router B nach dem Update von Router A die Information, das Netz 1 noch über Router C mit Hopcount 3 erreichen zu können. Router C hat seine Routingtabelle ja noch nicht aktualisiert und sendet diese veraltete Information weiterhin an seine Nachbarn, bis er von dort den Hopcount 16 erfährt. Damit übernimmt Router B dann die Route in das Netz 1 mit Hopcount 4.

	Router B würde beim nächsten Austausch Hop 4 an Router C senden, dieser übernimmt diese Information und trägt Hop 5 in seine Routingtabelle ein, da er bisher bereits Netz 1 über Router B erreicht. Somit schaukeln sich beide Router nach und nach bis auf Hop 16 auf - mit der entsprechenden Zeitlichen Verzögerung bis zur Konvergenz.		Router B würde beim nächsten Austausch Hop 4 an Router C senden, dieser übernimmt diese Information und trägt Hop 5 in seine Routingtabelle ein, da er bisher bereits Netz 1 über Router B erreicht. Somit schaukeln sich beide Router nach und nach bis auf Hop 16 auf – mit der entsprechenden Zeitlichen Verzögerung bis zur Konvergenz.

	Mechanismen zur Vermeidung spezieller Fälle dieses Problems sind [[Split Horizon]], [[Triggered Updates]] und (bei RIP mit IP) [[Split Horizon\|Split Horizon with Poisoned Reverse]]. Mit dem Erweiterungsalgorithmus RIP-MTI lassen sich Routing-Loops sogar vollständig erkennen und das Count-to-Infinity Problem tritt überhaupt nicht mehr auf.		Mechanismen zur Vermeidung spezieller Fälle dieses Problems sind [[Split Horizon]], [[Triggered Updates]] und (bei RIP mit IP) [[Split Horizon\|Split Horizon with Poisoned Reverse]]. Mit dem Erweiterungsalgorithmus RIP-MTI lassen sich Routing-Loops sogar vollständig erkennen und das Count-to-Infinity Problem tritt überhaupt nicht mehr auf.