Diskussion:Routing Information Protocol

"fehlende belege" abschnitt angebracht

das gilt eigentlich für fast den ganzen artikel. insbesondere aber: "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 OSI Protokoll IS-IS abgelöst worden."

• sicher ist nicht auszuschliessen dass jemand rip als technisch veraltet betrachtet. je mehr experte das gegenüber ist, desto unwahrscheinlicher dürfte eine solche aussage werden. gern wird die fallspezifische möglicherweise schlechtere eignung von distance-vector-protokollen in bestimmten einzelnen anwendungen (gerade von laien) mit 'veraltet' verwechselt.
• ospf und isis sind kein ersatz für rip - das sind link-state-protokolle und eine andere baustelle. auch das 'neuere' ist hier irreführend, die sind ebenfalls uralttechnologie (was eben - wie bei rip auch - ganz und gar nicht bedeutet dass sie mittlerweile irgendwie schlecht geworden wären) (nicht signierter Beitrag von 212.18.18.20 (Diskussion) 10:59, 2. Jul 2014 (CEST))

Welche Schicht?

RIP gehört zu der IGP Protokollfamilie, also ist RIP in Layer 3 (Schicht 3 - Vermittlung) einzuorden. (nicht signierter Beitrag von 213.252.167.86 (Diskussion) 23:40, 26. Jun. 2011 (CEST))

Würde gerne die Einordnung in das OSI Referenzmodell (oder den TCP/IP Protokollstack) hinzufügen. Hierzu gibt es wiedersprüchliche Angaben: Vermittlungsschicht (an sich logisch) oder Anwendungsschicht (vgl. Tanenbaum, Computernetzwerke). Was meint ihr dazu? -- Deki 20:15, 11. Feb 2005 (CET)

Eigentlich Netzwerkschicht. Nun könnte man noch auf die Idee kommen, RIP teilweise in die Transportschicht zu legen, da ja die Routinginformationen per UDP ausgetauscht werden. Aber Anwendungsschicht? Was sagt denn Guru Tanenbaum dazu? Eddia 14:26, 12. Feb 2005 (CET)

Tanenbaum hat eine Grafik in seinem Buch, wo das RIP auf der Anwendungsschicht steht, da es zum Informationsaustausch das UDP verwendet. Aus urheberechtlichen Gründen darf ich die Grafik hier leider nicht einfügen. Werde nochmal nachlesen, wie das genau gemeint ist. -- Deki 09:29, 13. Feb 2005 (CET)

Auf welcher Seite ist denn die Grafik im Tanenbaum?

An dieser Frage scheiden sich die Geister und ich glaube dass irgendwo beides zutrifft, je nachdem wie man argumentiert. Geht man davon aus, das die Aufgabe der Vermittlungsschicht die reine Weitervermittlung von Datenpaketen auf Basis von Routingtabelleneinträgen ist, braucht sich die Schicht nicht weiter darum zu kümmern, wie diese Einträge zustandekommen. Dafür wäre dann eine Anwendung weiter oberhalb zuständig (und im wörtlichen Sinne von "protocol stack" müsste dann RIP auf jeden Fall über UDP liegen). Andererseits kann man auch sagen, dass die Aufgaben, die ein Routingprotokoll erfüllt ein so integraler Bestandteil des ganzen Ablaufs sind, dass dies auf jeden Fall in die Vermittlungsschicht gehört. Ein Informatik-Prof. von mir hat sich diesbezüglich etwa so geäußert: "[...] Diese Protokolle sind die, die die Routing-Tabellen füttern und damit sind sie natürlich elementar für die Vermittlungsschicht zuständig, allerdings setzt ein Protokoll wie RIP z.B. auf UDP auf. Damit ist es schwierig, hier ganz klar die Schichtung aufzuzeigen." Ich persönlich würde dazu neigen, die Routingprotokolle aufgrund der erstgenannten Argumentation in die Anwendungsschicht zu zeichnen, da für die Verwaltung der Routingtabellen Anwendungsprozesse wie routed (Route Management Deamon) verantwortlich sind. -- anonymer Student

Anforderung der Routing-Tabelle

Was sagt ihr dazu, dass in diesem Artikel erwähnt wird, dass ein Router vom Nachbarn eine Tabelle anfordert? Meiner Meinung tut RIP das nicht. Meiner Meinung nach werden die Routingtabellen in regelmäßgen Abständen (alle 30 Sek.) bzw. nach Änderungen aktualiseirt (an die direkten Nachbarn geschickt).

Sehe ich genauso und werde das auch ändern. Auch von einem "Austausch" kann nicht direkt die Rede sein.

Wenn man mal ins RFC 1058 schaut steht unter 3.1 Message Format, dass es auch eine REQUEST Nachricht gibt, mit der man ein System dazu auffordern kann, seine Routingtabelle oder einen Teil davon zu senden. Ich finde auch, dass die Beschreibung für die Felder im RIP-Datenpaket fehlen. --Tukane 14:53, 17. Jul. 2007 (CEST)

Count-to-Infinity fehl am Platz?

Da das Count-to-Infinity-Problem ein grundsätzliches aller Dintanz-Vektor-basierten Verfahren ist, würde ich dies eher an der Stelle erklären, bzw. eventuell auch in einem eigenen Wikipedia-Artikel. M. E. gehört das nicht in diesem Umfang in diesen Artikel, ein Verweis genügt.

Routingprotokoll

Dass "ein Routingprotokoll [...] der dynamischen Erstellung der Routingtabelle von Routern" dient sollte selbsterklärend sein und ist m.E. deswegen redundant. Wer nicht weiss, was ein Routingprotokoll ist, muss ohnehin bei Routing oder Routingprotokoll nachlesen, deswegen reicht m.E. ein Link. Was meinen andere? --Matzedi 17:35, 7. Apr 2006 (CEST)

Leicht verständliche Erklärung für Routerkonfiguration.

Mit Verlaub, aber ich finde den Arktikel irgendwie wenig hilfreich. Es soll Leute geben, so wie mich z.B., die RIP irgendwo in ihren Routereinstellungen finden, bei mir steht da Ein oder Aus zu Auswahl, und das dann bei Wikipedia eingeben. Ich habe nach Durchlesen des Artikels jetzt zwar eine Vorstellung um was es gehen könnte, ob ich das jetzt aktivieren sollte, oder nicht, da muss ich dann doch leider eine andere Webseite um Rat fragen. --Lastwebpage 16:35, 15. Dez. 2008 (CET)

Fehler im Beispiel und im loop?

Die hops, welche im Beispiel angegeben sind scheinen mir falsch zu sein. Wenn Netz 1 direkt mit Router A verbunden ist, hat dieser in seiner Tabelle den hop count 0. Entsprechend reduzieren sich dann die hops zu den Routern B und C um eines.

Was mir auch nicht ganz einleuchtet ist die Sache mit dem routing loop. Oben im Artikel steht, dass nur neue Routingeinträge in die Tabelle geschrieben werden die besser sind als die bereits vorhandenen. Also wird nie eine route zu XY mit 5 hops durch eine route mit 6 hops überschrieben. Das ist meiner Meinung nach auch richtig so... Dann passt aber der Satz mit dem loop nicht mehr. Router C hat 3 hops zum Netz 1 in der Tabelle stehen. Wenn Router B ihm nun die Info schickt, dass er eine route zum Netz 1 hat mit 4 hops sollte Router C sich darum nicht kümmern und die Info verwerfen. Es zählen also keine Tabelleneinträge bis 16 hoch und werden dann auf "infinity" gesetzt. Ist es nicht so, dass ein normales Paket, welches per RIP geroutet wird pro hop seinen count im header um eines höher setzt? Wenn dieses Paket dann in einen solchen loop gerät "springt" es 15 mal hin und her und beim 16. Mal wird es verworfen. Da bin ich mir aber gerade auch nicht mehr 100%ig sicher...

Meinungen dazu? --Friday 13th 18:38, 28. Feb. 2009 (CET)

Der Hop-Count ist meiner Meinung nach Falsch. Wenn man den RFC 2453 zu Rate zieht ist auf Seite 13 folgendes Beispiel: https://tools.ietf.org/html/rfc2453#page-13

    A-----B
     \   / \
      \ /  |
       C  /    all networks have cost 1, except
       | /     for the direct link from C to D, which
       |/      has cost 10
       D
       |<=== target network

Each router will have a table showing a route to each network.

However, for purposes of this illustration, we show only the routes from each router to the network marked at the bottom of the diagram.

* D:  directly connected, metric 1
* B:  route via D, metric 2
* C:  route via B, metric 3
* A:  route via B, metric 3

Also das direkt angeschlossene Netzwerk von Router A hat die Metrik 1 hop, nicht 0 hop, wie jetzt im Artikel angegeben. --Dannori (Diskussion) 22:17, 21. Okt. 2019 (CEST)

Split Horizon

Split Horizon erst bei RIPv2? Laut diesem Beitrag --Biezl ✉ 17:45, 6. Apr. 2009 (CEST)

Konvergenzzeit falsch?

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

In tools.ietf.org/html/rfc2453#section-3.9.2 wird ein "triggered update" definiert, dass bei einer Routing-Änderung sofort gefeuert wird. Eine Routing-Änderung wird im Netz damit in deutlich kürzerer Zeit als 7 Minuten propagiert.

Einwände? Hinweise?

"Durch Nutzung des BFD-Protokolls durch RIP lassen sich Konvergenzzeiten im Millisekundenbereich erzielen." (später im Artikel) - spricht auch dafür