Routing Information Protocol (RIP) Version 1 Gateway of last resort

Transkript

1 1 of 8 Routing Information Protocol (RIP) Version 1 Gateway of last resort <DRUCK-Version als PDF> Dieser Abschnitt behandelt das erzeugen und versenden eines IPv4 Gateway of last resort oder einer Default-Route unter RIP. Wir nutzen das im Teil 2 erstellte Netzwerk. Bitte bedenke beim arbeiten mit RIPv1: Das Protokoll wurde 1969 für das Arpanet entwickelt um es unter allen Umständen Stabil zu halten. Also erwarte keine High-Speed Konvergenz! Gateway of last resort Als erstes soll ein Gateway of last resort auf dem Router Hamburg eingerichtet werden. Es existieren zwei verschiedene Möglichkeiten ein Gateway of last resort in unserer RIP-Domain zu

2 2 of 8 propagieren. Variante 1 Die erste Variante ist der Eintrag eines Default-Netzwerkes auf dem Router Hamburg, beispielsweise auf das Loopback0 Netz. Der RIP-Prozess hebt dieses automatisch in die Datenbank und propagiert es an die anderen Router. Sehen wir es uns auf dem Router Hamburg an. HAMBURG(config)#ip default-network HAMBURG(config)#exit 00:10:35: %SYS-5-CONFIG_I: Configured from console by console show ip rip database /0 redistributed [0] via , /8 auto-summary /8 directly connected, Loopback0 Prima, der Router Hamburg hat ein Gateway of last resort in seiner Datenbank. Kontrollieren wir das Propagieren durch den Debug-Befehl debug ip rip debug ip rip RIP protocol debugging is on 00:12:42: RIP: sending v1 update to via Serial1/0 ( ) 00:12:42: RIP: build update entries 00:12:42: subnet metric 1 00:12:42: network metric 1 Jau, er sendet Update-Pakete für das Subnet Folgerichtig sollte der Router Frankfurt dieses Update-Paket erhalten und in sein RIP-Datenbank aufnehmen. Kontrolle auf dem Router Frankfurt mittels show ip rip database. FRANKFURT#show ip rip database /0 [1] via , 00:00:07, Serial1/0 Dann sollte es auch in der Routingtabelle auftauchen. Sehen wir uns das mal an. FRANKFURT#show ip route Gateway of last resort is to network

3 3 of 8 R /8 [120/2] via , 00:00:17, Serial1/2 Variante eins ist also auf den ersten Blick erfolgreich, doch was macht der Router Hamburg mit den "angesaugten" Paketen? Sehen wir uns die Routingtabelle auf dem Router Hamburg an. show ip route Gateway of last resort is not set R /8 [120/3] via , 00:00:19, Serial1/0 Der hat ja gar kein Gateway of last resort. Nanu, der Befehl sorgt zwar für ein propagieren des Gateways of last resort aber noch lange nicht für einen Eintrag in die Routingtabelle. Damit es also funktioniert ist noch eine statische Route auf dem Router Hamburg notwendig, das geht wie folgt. HAMBURG(config)#ip route Loopback0 Sehen wir uns das Resultat in der Routingtabelle an. show ip route Gateway of last resort is to network R /8 [120/3] via , 00:00:26, Serial1/0 Jetzt kann der Router Hamburg die angesaugten Pakete verarbeiten und sendet diese auf dem Loopback 0 Interface hinaus. Löschen der Befehle auf Router Hamburg für die Variante 2: HAMBURG(config)#no ip default-network HAMBURG(config)#no ip route Loopback0 HAMBURG(config)#^Z Anschließend kontrollieren wir auch gleich auf dem Router Berlin, ob die Löschung erfolgreich war. FRANKFURT#show ip route

4 4 of 8 Gateway of last resort is to network R /8 [120/2] via , 00:00:00, Serial1/2. Nanu, ist ja noch da. Warum das denn? Sehen wir mal in der RIP Datenbank nach. FRANKFURT#show ip rip database /0 [1] via , 00:02:43, Serial1/ /8 auto-summary /8 [1] via , 00:00:24, Serial1/0 Merke: RIP ist keine Rakete!! Es dauert etwas länger!! Wie lange kann man mit show ip protocols ermitteln. FRANKFURT#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 19 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Triggered RIP Key-chain Serial1/ Serial1/ Serial1/ Laut dem Invalid Timer sollte 180 Sekunden nach dem letzten Update das Gateway of last resort auf jedem Router verschwunden sein. Zeit für einen Kaffee! Drei Minuten später sieht es auch gleich besser aus. FRANKFURT#show ip route Gateway of last resort is not set

5 5 of 8 R /8 [120/2] via , 00:00:02, Serial1/2 Zum Vergleichen hier meine Konfiguration des Router Hamburgs: configs/hamburg-confg_default-network.txt Variante 2 Wenden wir uns jetzt der zweiten Variante zu. Dabei konfigurieren wir dem Router Hamburg, innerhalb des Routing Prozesses, das Gateway of last resort. Das erfolgt durch den "default-information originate" Befehl. HAMBURG(config)#router rip HAMBURG(config-router)#default-information originate HAMBURG(config)#^Z Sehen wir lieber in der RIP Datenbank nach, ob der Befehl auch die gewünschte Wirkung zeigt. show ip rip database /0 redistributed [0] via , /8 auto-summary /8 directly connected, Loopback0 Prima, die Datenbank kennt den Präfix /0. Kontrollieren wir also, auf dem Router Frankfurt, wie die Auswirkung des Befehles ist. FRANKFURT#show ip route Gateway of last resort is to network R /8 [120/2] via , 00:00:04, Serial1/2 R* /0 [120/13] via , 00:00:12, Serial1/0 Ganz prächtig. Der Router Frankfurt hat sein Gateway of last resort in Richtung Router Hamburg liegend. Warum soviel Text für einen anderen Befehl? Tröt - is mir doch egal. Ist es eben nicht. Mit dem Default-Information Originate kann man über eine Route-Map die Metric des /0 Update-Paketes anpassen. Beispielsweise um die maximale Ausbreitung des Gateways of last resort zu steuern. Das flechten wir doch gleich mal mit ein und beschließen der Router Berlin soll das Gateway of last resort mit einer Metric von 15 in seiner Routingtabelle haben. Hm, wie geht das? Der Router Berlin ist zwei Hops von Hamburg entfernt, dann sollte eine Metric von 13 in Hamburg zum gewünschten Resultat führen. Probieren wir es einfach aus.

6 6 of 8 HAMBURG(config)#ip prefix-list GATEWAYOFLASTRESORT permit /8 HAMBURG(config)#^Z Jetzt sehen wir nach, was der Router aus unserer Prefix-List gemacht hat. show ip prefix-list ip prefix-list GATEWAYOFLASTRESORT: 1 entries seq 5 permit /0 Na dann lasst uns eine Route-Map für unsere Prefix-Liste bauen. HAMBURG(config)#route-map DER_ABFLUSS permit HAMBURG(config-route-map)#match ip address prefix-list GATEWAYOFLASTRESORT HAMBURG(config-route-map)#set metric +13 Und einbinden in den RIP-Routingprozess HAMBURG(config-route-map)#router rip HAMBURG(config-router)#default-information originate route-map DER_ABFLUSS HAMBURG(config-router)#^Z Sehen wir uns an, was der Router Hamburg macht. Zuerst werfen wir einen Blick in die RIP Datenbank. show ip rip database /0 redistributed [13] via , /8 auto-summary Der Eintrag für das Gateway of last resort ist angelegt. Jetzt prüfen wir nach, ob er diese Information auch an seinen Nachbarn, den Router Frankfurt, versendet. debug ip rip RIP protocol debugging is on 00:04:00: RIP: received v1 update from on Serial1/0 00:04:00: in 1 hops 00:04:00: in 2 hops 00:04:01: RIP: sending v1 update to via Serial1/0 ( ) 00:04:01: RIP: build update entries 00:04:01: subnet metric 13 00:04:01: network metric 1 Sieht gut aus. Er schickt über das Interface Serial 1/0 die Information mit der eingestellten Metric von 13. Dann dürfte das Etappen ziel erreicht sein. Prüfen wir also, was der Router Berlin in der Routingtabelle als Gateway of last resort stehen hat. BERLIN#show ip route

7 7 of 8 Gateway of last resort is to network C /8 is directly connected, Loopback1 R /8 [120/1] via , 00:00:12, Serial1/0 R* /0 [120/15] via , 00:00:12, Serial1/0 BERLIN# Der Router Berlin spiegelt unsere Erwartungen wieder. Wie immer stellt sich die Frage, würde das jetzt Funktionieren? Die Antwort ist dummerweise wieder: Nein Lenken wir unsere Aufmerksamkeit nochmal auf den Router Hamburg und sehen uns an, wohin er Pakete sendet die zu keinem Eintrag in der Routingtabelle passen. show ip route Gateway of last resort is not set R /8 [120/3] via , 00:00:25, Serial1/0 Welch ein Dilemma, das Gateway of last resort wird auch bei dieser Variante nicht automatisch gesetzt. Dann wollen wir ihm, dem Router Hamburg, mal mit einer statischen Route auf die Sprünge helfen. HAMBURG(config)#ip route loopback 0 HAMBURG(config)#^Z Mal sehen, ob das zum gewünschten Eintrag in der Routingtabelle führt show ip route Gateway of last resort is to network

8 8 of 8 R /8 [120/3] via , 00:00:11, Serial1/0 R /8 [120/2] via , 00:00:15, Serial1/0 S* /0 is directly connected, Loopback0 Last uns mal den Unterschied zwischen diesen beiden Varianten untersuchen. Bei Variante 1 kann man keine Metric angeben und die Information über das Gateway of last resort wird versendet, sobald das Netzwerk /8 verfügbar ist. Bei Variante 2 kann man die Ausbreitung des /0 Updates mit der Metric steuern und man kann mehrere Randbedingungen prüfen, bevor die Information versendet wird. Sehen wir uns an ob die Randbedingungen wirklich geprüft werden, dies sollte sich in der Prefix-Liste widerspiegeln. Ist der Eintrag in der RIP-Datenbank? show ip rip database /0 redistributed [13] via , Sollte es mal trotz der richtig Konfiguration nicht der Fall sein, hilft ein kleiner Schubs. clear ip route * Und nun sehen wir uns an, ob die Prefix-Liste zyklisch abgefragt wird. Leider ist mir dafür keine debug-befehl bekannt. Wir können es deshalb nur an der Menge, der durch die Prefix-Liste gelaufenen Pakete erkennen. show ip prefix-list detail Prefix-list with the last deletion/insertion: GATEWAYOFLASTRESORT ip prefix-list GATEWAYOFLASTRESORT: count: 1, range entries: 0, sequences: 5-5, refcount: 3 seq 5 permit /8 (hit count: 86, refcount: 1) 40 Sekunden warten show ip prefix-list detail Prefix-list with the last deletion/insertion: GATEWAYOFLASTRESORT ip prefix-list GATEWAYOFLASTRESORT: count: 1, range entries: 0, sequences: 5-5, refcount: 3 seq 5 permit /8 (hit count: 89, refcount: 1) Tatsächlich wird periodisch geprüft, ob der IPv4 Prefix /8 vorhanden ist. Sehr schön am hoch zählenden Hit-Count zu erkennen. Zum Vergleichen hier meine Konfiguration des Router Hamburgs: configs/hamburg-confg_default-infomation_originate.txt