10. Totalausfall des Netzwerks
Habe ich an einem Rechner überhaupt keine Verbindung zum Netz, oder kann ich ein ganzes Netzsegment nicht erreichen, spreche ich von einem Totalausfall.
Dabei unterscheide ich zwei Arten, je nachdem, von wo ich das Problem betrachte. Untersuche ich es von einem Rechner, der überhaupt keine Verbindung hat, dann sehe ich das Problem von innen, weil ich versuche, mit dem Rechner innerhalb eines Segments eine Verbindung zu bekommen. Kann ich ein ganzes Netzsegment nicht mehr erreichen, dann betrachte ich das Problem von außen, da ich mich in einem anderen Segment befinde und andere Rechner erreichen kann, nur dieses Netzsegment und die Rechner darin nicht.
Bei der Betrachtung von innen, überprüfe ich die Schichten des OSI-Modells von unten nach oben. Das heißt, ich fange bei der Kabelverbindung zum Switch an und arbeite mich zur IP-Konfiguration hoch, bis ich Kontakt zu mindestens einem anderen Rechner bekomme.
Bei der Betrachtung von außen muss ich die Topologie des Netzwerks kennen. Dann überprüfe ich den Weg zum nicht erreichbaren Segment und kontrolliere auf dem letzten erreichbaren Gateway dorthin die physikalische Verbindung und die Routen. Auf diese Weise arbeite ich mich bis zum ausgefallenen Netzsegment vor.
Netzausfall an einem Rechner
Komme ich zu einem Rechner, der überhaupt keine Verbindung zum Netz hat, dann beginne ich in der untersten Schicht, der physikalischen oder Bitübertragungsschicht im OSI-Modell und arbeite mich von da langsam nach oben über die Sicherungsschicht zur Vermittlungsschicht.
Bei neu gestarteten Systemen kontrolliere ich als erstes die
Zuordnung der Schnittstellennamen mit ifconfig oder ip addr show.
Es gibt keine zuverlässige Möglichkeit, Netzschnittstellen von vornherein eindeutig zu benennen.
Traditionell heißen Ethernetschnittstellen eth0, eth1, … Sobald mehrere Schnittstellen eingebaut sind, ist es nicht mehr trivial, zu bestimmen, welche physische Schnittstelle eth0 ist. Die Nummerierung kann sich von einer Kernel-Version zur anderen ändern, was glücklicherweise eher selten vor kommt. Meist ändert sie sich, wenn jemand einen Controller aus- oder einbaut.
Aus diesem Grund wird bei Debian via udev beim Systemstart für jede bisher unbekannte Ethernet-Karte eine Regel in /etc/udev/rules.d/70-persistent-net.rules generiert, die den nächsten freien Namen mit der MAC-Adresse der Karte verknüpft. Damit bleibt die Zuordnung immer gleich, unabhängig davon, ob ich Ethernetkarten hinzufüge oder ausbaue.
Wenn ich einen Klon dieses Systems in einen Rechner mit anderen MAC-Adressen der Ethernetkarten einbaue, dann ändern sich alle Schnittstellennamen. Statt eth0, eth1, eth2 finde ich dann eth3, eth4, eth5 im System vor. Damit stimmt die alte Schnittstellenkonfiguration in /etc/network/interfaces nicht mehr und der Rechner ist über Netzwerk nicht zu erreichen.
Na gut, mag man einwenden, aber wann kommt so etwas denn vor? Zum Beispiel, wenn ich ein bestehendes System virtualisiere, oder wenn ich ein virtualisiertes System klone, oder wenn ich ein System, welches von Flashspeicher betrieben wird, in eine andere Hardware kopiere.
Die Abhilfe ist einfach. Ich entferne alle Einträge aus der Datei /etc/udev/rules.d/70-persistent-net.rules und starte das System neu.
Nachdem ich mich von der korrekten Nummerierung der Netzschnittstellen überzeugt habe, schaue ich nach, ob die Verbindung mit dem Hub, Switch oder Rechner am anderen Ende des Kabels funktioniert.
Dafür brauche ich keinen neuen Befehl aufrufen, das sagt mir ebenfalls ip:
$ ip addr show
...
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> ...
link/ether 00:1f:d0:97:c4:55 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
link/ether 00:00:e8:df:92:b0 brd ff:ff:ff:ff:ff:ff
...
Die Angabe NO-CARRIER in spitzen Klammern zeigt mir, dass eth0 keine
Verbindung hat.
Hier muss ich die Verkabelung prüfen.
Bevor ich zur nächsten Ebene im OSI-Modell übergehe, stelle ich sicher, dass ich durch Überprüfung der Kabelverbindung und gegebenenfalls Austausch defekter Komponenten eine funktionsfähige physische Verbindung hergestellt habe.
Melden Treiber und ip eine Kabelverbindung, will ich als nächstes
sehen, dass auch Daten darüber ankommen.
Mit dem Befehl netstat -i sehe ich, ob Daten über die
Schnittstelle empfangen oder gesendet wurden:
$ netstat -i
Kernel-Schnittstellentabelle
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK ...
eth0 1500 0 0 0 0 0 0 ...
eth1 1500 0 44921 0 0 0 28889 ...
...
Hier sehe ich, dass an eth1 Daten ankamen und gesendet wurden.
Allerdings weiß ich noch nicht, ob die Schnittstellen am
richtigen Netz angeschlossen sind.
Mit ip addr show lasse ich mir die Adressen anzeigen und vergleiche diese
mit der erwarteten Konfiguration.
Stimmt diese überein, dann versuche ich mit Ping einen Rechner in jedem
angeschlossenen Netz zu erreichen.
Bekomme ich keine Antwort können die Karten noch im falschen Netz
angeschlossen sein.
Das überprüfe ich mit:
# tcpdump -n -i $if
das mir den Verkehr am betreffenden Interface anzeigt. Dabei schaue ich nach Broadcasts und ARP-Anfragen, die mir zeigen, in welchem Netzsegment das Interface angeschlossen ist. Nötigenfalls tausche ich die Kabel, bis alle Schnittstellen mit dem richtigen Netzsegment verbunden sind.
Sobald ich irgendeinen Rechner im direkt angeschlossenen Netzsegment erreichen kann, habe ich es nicht mehr mit einem totalen Netzausfall des Rechners zu tun.
Dann schaue ich als nächstes nach, ob ein Gateway definiert ist, ob ich dieses erreichen kann und schließlich, ob ich irgend einen Rechner hinter dem Gateway erreiche. Aber das gehört schon zu einem anderen Themenkreis und steht an anderer Stelle in diesem Buch.
Totalausfall Netzsegment
Neben dem totalen Ausfall der Anbindung eines Rechners an das Netz betrachte ich die Nichterreichbarkeit eines oder mehrerer Netzsegmente als Totalausfall. Während ich bei ersterem auf die Kenntnis der Hardware und der unteren OSI-Schichten setze, um den Fehler einzugrenzen, benötige ich hier detaillierte Kenntnisse der Netzwerktopologie.
Mein erster Blick gilt den Routen.
Mit netstat, ip oder route kann ich mir diese anzeigen lassen.
Da die Ausgabe in Netzen mit sehr vielen Routen sehr
unübersichtlich ist und die Routen nach anderen Kriterien sortiert sind
als nach der schnellen Auffindbarkeit eines Netzes, lautet die komplette
Befehlszeile bei mir meist:
$ netstat -rn | sort | less
Finde ich die Route zum ausgefallenen Netzsegment, überprüfe ich als
nächstes mit traceroute, wie weit ich auf dem Weg dorthin komme.
Fehlt die Route, schaue ich in die Topologiedaten und suche nach dem letzten erreichbaren Netzsegment vor dem ausgefallenen. Dann muss ich mich, von diesem Segment aus, Schritt für Schritt vorarbeiten. Dazu melde ich mich auf den Gateways an und schaue, ob das jeweils nächste Gateway auf dem Weg erreichbar ist.
Neben den Netzwerk-Schnittstellen kontrolliere ich auf den Gateways auch die Routen. Und zwar in beide Richtungen, zum ausgefallenen Netzsegment und zurück zu dem Segment, von dem aus ich den Fehler suche. Mitunter kommen meine Datenpakete im ausgefallenen Netzsegment an, aber die Antwort nicht, da die Rückroute fehlt. In diesem Fall kann ich mich nicht direkt am Gateway mit der fehlenden Rückroute anmelden. Die Anmeldung von Gateway zu Gateway funktioniert aber oft noch, so dass ich darüber die Konfiguration und die Routen kontrollieren kann.
Je nachdem, ob ich auf dem Gateway ein Problem mit der physischen Verbindung zum nächsten Hop habe, oder ob eine der benötigten Routen fehlt, arbeite ich jetzt weiter.
Bei Problemen mit der physischen Verbindung untersuche ich das Problem bei einem Linux-basierten Router, wie im vorigen Abschnitt beschrieben.
Bei fehlenden Routen muss ich mich näher mit den Routing-Protokollen beschäftigen.
In dringenden Notfällen kann ich mir mit einer statischen Route weiterhelfen, aber das sollte die Ausnahme sein. Wenn im Netz ein Routingprotokoll verwendet wird, so ist es besser, die Routen darüber zu verbreiten, weil damit Änderungen im Netz automatisch an alle Gateways bekanntgegeben werden. Eine vergessene statische Route kann auf sehr subtile Weise zu Netzwerkfehlern führen, die mitunter schwer zu finden sind.
Statische Routen eintragen
Es gibt mehrere Möglichkeiten, eine statische Route auf einem Linux-System einzutragen. Der direkte Weg von Kommandozeile aus geht über
# route add -net $destination gw $gateway
oder
# ip route add $destination via $gateway
Damit diese statische Route den nächsten Systemstart überlebt, trage ich den Befehl bei auf Debian basierenden Systemen in /etc/network/interfaces ein. Sinnvollerweise bei dem Interface, über das die Verbindung zum Gateway geht:
iface eth0 inet static
...
up ip route ...
Bei Systemen, die auf Fedora oder Redhat basieren, trage ich die Route unter /etc/sysconfig/ in die passende Datei ein.
Eine andere Möglichkeit, eine statische Route einzutragen, geht über das Programm quagga. Dieses ist auf einem Gateway vermutlich sowieso installiert.
Hier melde ich mich am zebra Dämon an und trage die statische Route ein:
$ telnet localhost 2601
zebra> enable
zebra# conf t
zebra(config)# ip route $destination $gateway
zebra(config)# end
zebra# write file
zebra# quit
Mit dem Befehl write file speichere ich die Konfiguration permanent,
so dass sie den nächsten Neustart überlebt.
Routingprobleme
“Die Kunden beschweren sich über Verbindungsabbrüche, kannst Du bitte mal die Leitung prüfen.”
So oder so ähnlich höre ich es ab und zu von den Kollegen, ich sehe mir die Leitung an und kann oft nichts Auffälliges entdecken.
Da wir ein relativ komplexes Netz betreiben, mit mehreren Dutzend Segmenten, verwenden wir Routingprotokolle, um den Gateways die Routen bekannt zu machen.
Und diese Routingprotokolle, so sehr sie die Arbeit auch erleichtern, bringen zusätzliche Angriffsflächen in das System, über die sich Fehler einschleichen können.
Nun kann ich mich auf den Standpunkt stellen: ich eliminiere diese Fehlerquelle, indem ich nur statische Routen verwende. Bis zu einer gewissen Anzahl von Netzsegmenten ist das eine vernünftige Entscheidung. Irgendwann aber kommt der Punkt, ab dem ich die nötige Sorgfalt beim Eintragen der statischen Routen nicht mehr aufbringen kann oder will. Wo diese Grenze ist, muss jeder für sich entscheiden. Insbesondere, wenn es temporäre Netze gibt, die nach wenigen Tagen bereits wieder ausgetragen werden müssen, verschiebt sich diese Grenze für mich sehr schnell nach unten.
Was kann ich tun, wenn ich auf Grund der Komplexität des Netzes ein oder mehrere Routingprotokolle einsetze und bei festgestellten Verbindungsabbrüchen sicher gehen will, dass diese nicht vom Routing verursacht wurden?
An dieser Stelle setze ich einmal mehr auf Monitoring, also lückenlose Beobachtung der Routen im Netz. Gerade ein Rechnernetz ist ein Paradebeispiel für ein verteiltes System, dessen Funktionieren vom Funktionieren seiner Komponenten abhängt. Ich bin daran interessiert, so früh, wie möglich festzustellen, wenn eine Komponente nicht mehr funktioniert.
Wie kann ich Netzwerkrouten überwachen?
Sicher gibt es für dieses Problem kommerzielle Systeme, mit denen ich das Netzwerk und Routingprobleme darin bequem und einfach diagnostizieren kann. In diesem Buch geht es aber um freie Software und darum, ein Verständnis für das untersuchte Problem zu entwickeln.
Ich kann mit der - zumindest von mir - unter Linux am häufigsten eingesetzten Routingsoftware Quagga nicht nur meinen Rechner selbst am Routingprotokoll teilnehmen lassen, sondern auch über die Debugfunktionen den Zustand der Protokolle analysieren und über die Protokollfunktion das Routing überwachen.
Will ich nur mitbekommen, wann welche Route im Netz hinzukam oder
verschwand, wende ich mich direkt an den Dämon zebra.
Ich schalte das Logging ein und teile ihm mit, welche Informationen ich haben
will.
$ telnet localhost zebra
zebra> enable
zebra# conf t
zebra(config)# log syslog
zebra(config)# debug zebra rib
zebra(config)# end
zebra# write file
Dadurch, das ich zebra via Syslog protokollieren lasse, kann ich die
Auswertung auf einem anderen Rechner vornehmen, wenn syslogd entsprechend
konfiguriert ist.
Mit debug zebra rib habe ich ihm mitgeteilt, dass ich Informationen zur
Routing Information Base haben will.
Daraufhin finde ich Einträge wie diese für entfernte Routen:
Logeinträge für entfernte Routen
Die Einträge für hinzugekommene Routen sehen so aus:
Logeinträge für hinzugefügte Routen
Diese Logzeilen sind schon sehr informativ, für eine schnelle Auswertung auf einen Blick aber zu unübersichtlich.
Ich nehme daher mein Standardgerüst für Perl-Skripts zur Syslog-Auswertung und ergänze dieses um die folgenden Zeilen:
1 my $wanted = 'zebra';
2 my $ip4 = qr|(\d{1,3}(?:\.\d{1,3}){3}/\d{1,2})|;
3 my $del = qr|^rib_process: $ip4: Removing existing|;
4 my $add = qr|^rib_process: $ip4: Adding route|;
5 sub process_line {
6 my ($time,$host,$name,$pid,$text) = @_;
7 if ($text =~ /$del/) {
8 print "$time $host $name: remove $1\n";
9 }
10 elsif ($text =~ /$add/) {
11 print "$time $host $name: add $1\n";
12 }
13 }
In Zeile 1 lege ich die gewünschten Logzeilen anhand des Prozessnamens fest.
Zeilen 2 bis 4 definieren reguläre Ausdrücke, die mir die Informationen aus
den Logzeilen beschaffen. Die Netzadresse der Route landet in der temporären
Variable $1, die ich in den Zeile 8 für die entfernten und Zeile 11 für die
zugefügten Routen ausgebe.
Damit sieht die Ausgabe dann so aus:
Aug 26 10:16:43 netinfo1 zebra: remove 10.10.0.0/16
Aug 26 10:16:47 netinfo1 zebra: add 0.0.0.0/0
Aug 26 10:16:47 netinfo1 zebra: add 10.0.0.1/32
Aug 26 10:16:47 netinfo1 zebra: add 10.147.0.0/16
Alternativ hätte ich die Änderungen auch in eine Datenbank schreiben können, die ich dann interaktiv abfragen könnte.
Sagt mir mein Routing-Monitor, dass ein festgestellter Verbindungsabbruch mit einer Routingänderung einhergeht, muss ich mich näher mit den Routingprotokollen beschäftigen.
Ein sehr guter Einstieg in das Thema ist [Malhotra2002]. Zum einen, weil er auf die Protokolle detailliert eingeht und zum anderen, weil ich die für Cisco IOS geschriebenen Konfigurationsbeispiele mit Quagga sehr gut nachvollziehen kann.
RIP-2
RIP-2 ist ein sehr einfaches und robustes Protokoll, das seinem Vorgänger RIP vor allem mit der Fähigkeit zu CIDR überlegen ist. Es ist in RFC 2453 beschrieben, RFC 4822 ergänzt es um kryptographische Authentisierung. RIP und RIP-2 nutzen den Distance-Vektor-Algorithmus zur Berechnung der Routen. Außerdem kann es die Next-Hop-Address zu einer Route angeben, wodurch ich mit RIP-2 einen Übergang zu anderen Routing-Protokollen schaffen kann. Weiterhin ist es möglich, Authentisierungsdaten zu verwenden, um die Quelle eines RIP-2-Datagramms zu verifizieren.
Die Authentisierungsdaten schützen meine Router davor, fehlerhafte Routen von zufällig im Netz eingesteckten fremden Routern zu übernehmen. Gleichzeitig verhindern sie den Austausch der Routen zwischen meinen Routern, falls ich die Authentisierungsinformationen falsch eingetragen habe.
Bei Problemen melde ich mich am RIP-Dämon an:
$ telnet localhost ripd
Dann kann ich den Zustand des RIP-Protokolls analysieren.
Zum Monitoring kann ich, wie beim zebra Dämon, verschiedene Debugbefehle
nutzen.
Insbesondere schaue ich nach, welche Nachbarn der Router kennt, wann er die
letzten Informationen von diesen bekommen hat und welcher Nachbar welche Route
anbietet.
Probleme mit RIP
Ich gehe hier nicht auf die in der Literatur zu findenden Probleme von RIP mit der Konvergenz bei bestimmten Netzwerkkonstellationen ein. Diese setze ich als bekannt voraus, ein Netzwerkadministrator wird mit diesen umzugehen wissen.
Stattdessen gehe ich auf Probleme ein, die mich einiges an Zeit und Nerven gekostet haben. Vielfach hatten diese mit proprietären Routern zu tun und haben dazu beigetragen, dass ich in meiner Arbeit lieber Open Source Systeme einsetze.
Vor einigen Jahren kam es in unregelmäßigen Abständen zu Totalausfällen des Netzwerks, die durch das Routing verursacht wurden und sich binnen weniger Minuten von allein erledigten. Das passierte relativ selten, so dass wir es zunächst nicht weiter verfolgten.
Mit Hilfe von Quagga konnte ich schließlich herausfinden, dass ein Router im zentralen Netz dann alle Routen auf sich zog und die Pakete nicht weiterleitete. Durch die Beobachtung der Lognachrichten von Quagga kam ich überhaupt erst auf diesen Router. Im Laufe der Zeit stellte sich heraus, dass das Problem immer dann auftrat, wenn die Konfiguration dieses Routers neu geladen wurde.
Damit hatte ich einen Hebel, mit dem ich das Problem gezielt hervorrufen und dann genau betrachten konnte.
Es stellte sich heraus, dass der Router beim Neuladen der Konfiguration alle Routen mit der Metrik 0 verbreitete. Diese war kleiner als alle anderen Metriken und der Router zog praktisch alle Routen auf sich. Da die anderen Router nun ihn als Gateway für die betreffenden Routen verwendeten, speisten sie die korrekten Routen nicht mehr im zentralen Netz ein. Nach Ablauf der RIP-Timeouts setzte der problematische Router die Metrik auf 16, der normale Konvergenzprozess begann und die Routen wurden wieder korrekt im Netz verteilt. In der Zwischenzeit waren aktive TCP-Verbindungen, die über das zentrale Netz liefen, beendet.
Es dauerte einige Zeit, bis ich diesen Fehler gefunden und verstanden hatte. Der Hersteller, den ich über das Problem informierte, schickte zwar einige Updates, von denen jedoch keines das Problem löste.
Im Endeffekt begannen wir damals, das Routing auf OSPF umzustellen - das konnten diese Router - und haben sie schließlich ganz ersetzt.
Ein anderes, nicht ganz so gravierendes Problem trat während der Umstellung des Routings auf OSPF auf. Einer der Router, die noch RIP2 verwendeten, wählte das falsche Gateway für die Route mit dem meisten Verkehr aus. Anstelle die Datagramme direkt an das korrekte Gateway zu senden, welches nur OSPF verwendete, schickte er die Datagramme an das Gateway, welches die Routen aus dem OSPF nach RIP2 umsetzte, obwohl dieses für jede Route das korrekte Gateway in seinen RIP2-Nachrichten angab.
Das Problem führte zu keinem Verbindungsausfall, aber zu einer erhöhten Netzlast auf dem Gateway, welches die Routen von OSPF nach RIP2 übertrug. Nachdem ich den problematischen Router ebenfalls auf OSPF umgestellt hatte, ging diese unnötige Netzlast um eine Größenordnung - also um den Faktor 10 - zurück.
Auch, wenn scheinbar alles funktioniert, ist es besser, ab und zu genauer in die Logs zu schauen beziehungsweise nach Anomalien im Netzverkehr Ausschau zu halten.
OSPF
OSPF ist ein hierarchisches Protokoll. RFC 2328 beschreibt die Version 2 für IPv4 und RFC 5340 OSPF für IPv6.
Ich teile das Netz in einzelne Areas (Gebiete) auf, die über eine Zentrale (Area 0) miteinander verbunden sind. Die Router in den Areas müssen lediglich die Routen innerhalb der Area und die Grenzrouter zu anderen Areas oder externen Netzen kennen. Das Protokoll verwendet den Link-State-Algorithmus für die Berechnung der Routen, das heißt, jeder Router kennt den Zustand aller Interfaces aller anderen Router seiner Area und berechnet selbst für sich den kürzesten Pfad für eine gegebene Route. OSPF konvergiert meist schneller bei Routingänderungen zum neuen Zustand des Netzes. Dafür ist die Berechnung der neuen Route CPU-intensiv.
Fehlersuche bei OSPF
Um das OSPF-Protokoll - genau genommen seinen Zustand - zu analysieren, melde
ich mich am ospfd von quagga an und arbeite überwiegend mit den über
show ip ospf erreichbaren Befehlen.
Mit show ip ospf interface sehe ich, welche Interfaces aktiv sind, am
OSPF-Protokoll teilnehmen und welche Nachbarn sie kennen.
Um mehr über die Nachbarn zu erfahren, verwende ich die über show ip ospf
neighbor erreichbaren Befehle.
Da OSPF sehr prozessorlastig ist, muss ich vielleicht nachsehen, ob ein Router überlastet ist. Dabei helfen mir die folgenden Faustregeln, um die zu erwartende Last grob einzuschätzen:
- ABR (area border router) machen mehr als interne Router
- DR (designated router) / BDR (backup designated router) machen mehr als andere Router
- Router in Stub Areas und NSSA (not so stubby areas) machen am wenigsten.
Gegebenenfalls setze ich an einigen Stellen leistungsstärkere Router ein oder sorge dafür, dass ein schwächerer Router nicht DR/BDR wird.
Mit dem Befehl show ip ospf bekomme ich heraus, wie oft der
OSPF-Algorithmus ausgeführt wurde, das heißt, wie oft die Routen neu berechnet
wurden:
ospfd> sh ip ospf
...
SPF algorithm last executed 12h37m18s ago
...
Area ID: 0.0.0.0 (Backbone)
...
SPF algorithm executed 4039 times
Wenn die letzte Zahl sehr hoch ist, und vielleicht noch wächst, während ich angemeldet bin, deutet das auf ein flatterndes Interface hin.
In diesem Fall kann ich mit den über debug ospf erreichbaren Befehlen nach
dem betreffenden Router fahnden und dann das Problem dort untersuchen.
Einfacher ist die Ursache manchmal zu finden, wenn ich sowieso alle
Routingänderungen protokolliere und anhand dieser Protokolle auf die Ursache
schließen kann.
Suche ich hingegen nach einer relativ stabilen aber falschen Route, dann kann
ich die Topologiedatenbank mit den über show ip ospf database erreichbaren
Befehlen untersuchen.
Gemischter Einsatz von statischen und dynamischen Routen
Setze ich in einem Netz sowohl statische als auch dynamische Routen ein, ist besondere Vorsicht geboten. Zum einen muss ich die Einspeisung der statischen Route in das dynamische Protokoll sorgfältig prüfen. Genauso wichtig ist die korrekte und vor allem wiederauffindbare Dokumentation dieser Besonderheit.
In einem konkreten Fall hatte ich eine statische Route an einem Border Router in das OSPF eingespeist. Beim Austausch des Routers am Next-Hop, über den die Route ging, wurde dieser ebenfalls in die OSPF-Area aufgenommen. Der ehemalige Border Router speiste weiterhin seine (für ihn korrekte) statische Route in die OSPF-Area. Der neu aufgenommene Router erhielt die korrekte Route via RIP-2, das niedriger priorisiert war und die (für ihn falsche) Route aus dem OSPF vom alten Border Router. Im Ergebnis sandte er die Datenpakete in die falsche Richtung und ich benötigte einige Zeit und Muße, bis ich durch Vergleich der OSPF-Routing-Databases der Router darauf kam und die statische Route als Verursacher ausmachte.