EIGRP im Netzwerk
aus ANOther Wiki, der freien Wissensdatenbank
EIGRP ist ein skalierbares Routingprotokoll, welches effizient arbeitet, schnell auf Änderungen reagiert und ausserdem Netzwerkwachstum ermöglicht, kurzum, ein Routingprotokoll für große Netze
EIGRP-Skalierbarkeit beeinflussende Faktoren:
| o | Quantität der Routinginformationen | Werden mehr Informationen als für das korrekte Routing unbedingt nötig sind zwischen den einzelnen Routern übertragen, müssen diese unnötig nehr arbeiten, und jede Aktion verlangsamt sich dadurch. Hier könnte Routesummarization entgegen wirken |
| o | Anzahl der beteiligten Router | Bei einer Änderung der Routingtopologie spielt auch die Anzahl der beteiligten Router eine Rolle. Je mehr Router an den Folgen der Änderung beteiligt sind, desto länger wird es dauern, bis die Änderung im gesamten Netz übertragen und eine neue, richtige Topologie aufgebaut ist |
| o | Topologie | Ebenso wie die Anzahl der Router hat auch die Tiefe des Netzwerkes direkte Auswirkung auf die Konvergenz |
| o | Anzahl der alternativen Pfade | Ein Router im Netzwerk sollte zu seinem Primärweg eine Ausweichroute zum Ziel gespeichert haben, um einen ausgefallenen Knoten zu umgehen. Zu viele alternative Routen allerdings können können allerdings zu weiteren Konvergenzproblemen führen, da bei allen Änderungen der Topologie alle alternativen Routen gefunden und berechnet werden müssen. Dies kann zu einem "SIA", einem "stock in action" führen, da der Router immer auf Antworten weitere alternative Routen betreffend wartet, die sich durch eben diese verteilen |
EIGRP im Netzwerk
aus ANOther Wiki, der freien Wissensdatenbank
EIGRP ist ein skalierbares Routingprotokoll, welches effizient arbeitet, schnell auf Änderungen reagiert und ausserdem Netzwerkwachstum ermöglicht, kurzum, ein Routingprotokoll für große Netze
EIGRP-Skalierbarkeit beeinflussende Faktoren:
| o | Quantität der Routinginformationen | Werden mehr Informationen als für das korrekte Routing unbedingt nötig sind zwischen den einzelnen Routern übertragen, müssen diese unnötig nehr arbeiten, und jede Aktion verlangsamt sich dadurch. Hier könnte Routesummarization entgegen wirken |
| o | Anzahl der beteiligten Router | Bei einer Änderung der Routingtopologie spielt auch die Anzahl der beteiligten Router eine Rolle. Je mehr Router an den Folgen der Änderung beteiligt sind, desto länger wird es dauern, bis die Änderung im gesamten Netz übertragen und eine neue, richtige Topologie aufgebaut ist |
| o | Topologie | Ebenso wie die Anzahl der Router hat auch die Tiefe des Netzwerkes direkte Auswirkung auf die Konvergenz |
| o | Anzahl der alternativen Pfade | Ein Router im Netzwerk sollte zu seinem Primärweg eine Ausweichroute zum Ziel gespeichert haben, um einen ausgefallenen Knoten zu umgehen. Zu viele alternative Routen allerdings können können allerdings zu weiteren Konvergenzproblemen führen, da bei allen Änderungen der Topologie alle alternativen Routen gefunden und berechnet werden müssen. Dies kann zu einem "SIA", einem "stock in action" führen, da der Router immer auf Antworten weitere alternative Routen betreffend wartet, die sich durch eben diese verteilen |
Inhaltsverzeichnis |
EIGRP-Queries
| + | Querries werden gesendet, wenn eine Route verloren geht, und keine geeignete Alternative vorhanden ist |
| + | Der Router sendet Anfrage zu allen benachbarten Routern auf allen Interfaces, bis auf das des vorangegangenen Sucsessors (Split Horizon) |
| + | Sollte ein Nachbar keinerlei Information, einen neuen Weg zum Ziel zu finden, kennen, fragt er wiederum seine Nachbarn, auf allen Interfaces, nur nicht auf dem, auf dem er gefragt wurde |
| + | Kennt ein Nachbar einen neuen Weg, teilt er diesen dem Anfragenden Router auf dem anfragenden Interface mit und stellt keine weiteren Anfragen. Anfragen, die sich in anderen Zweigen fortgesetzt haben können natürlich noch Ergebnisse bringen, oder eben nicht. Die Bewertung der gefundenen Routen obliegt dem Auftraggeber |
EIGRP-Stubs
| - | Das EIGRP-STUB-Route-Feature verbessert die Netzwerkstabilität, spart Ressourcen und erleichtert die Konfiguration der abgesetzten Stubrouter |
| - | STUB-Routing wird hauptsächlich in hub-and-spoke-Netzwerken verwendet |
| - | Ein Stub-Router sendet PAkete zu seinen Nachbarn, in denen er sie über seinen Status als Stub-Router informiert |
| - | Nachbarn von Stub-Routern, die ein solches Paket erhalten, senden keine Queries mehr an die Stub-Router |
Beispiel:
AB sowie wären per Backbone verbunden und hätten Verbindung zum Netz 10.0.0.0/24. CDE sind jeweils mit A und B verbunden, nicht aber untereinander
Die Verbindung zum Netz 10.0.0.0/24 fällt aus.
Die Router vermelden den Ausfall weiter, jeweils auf allen Interfaces, auf denen diese Melung nicht eingegangen ist.
Selbes passiert, wenn das Netz 10.0.0.0/24 wieder kommt
Nähme man nun an, die WAN-Verbindungen wäre eine langsame Leitung. Hier sollte verhindert werden, dass die oben beschriebenen Query-Stürme übe die langsamen Verbindungen übertragen werden. Allzuviel Sinn gäbe es ohnehin nicht, CDE sind Sackgassen, Stubs.
Konfiguration
R-ANO-01(config)#eigrp stub [receive-only|connected|static|summary]
| receive-only | ist der Router so konfiguriert, sendet er keine Updates |
| connected | der Router sendet Routen, die direkt verbunden sind. Unter Umständen muss redistributiert werden |
| static | der Router sendet statische Routen. Auch hier muss redistributiert werden |
| summary | es werden Zusammenfassungen gesendet |
In der Voreinstellung sind "connected" und "summary" aktiv
SIA Verbindungen
SIA-Routen (Stuck-In-Active) können zu einer der größten Herausforderungen werden, zu denen es in einem EIGRP-Netzwerk kommen kann.
Was passiert bei SIA?
| - | Ein Router muss alle Antworten auf ausstehende Queries von seinen Nachbarn erhalten, bevor er sie Sucessor-Route berechnen kann |
| - | Sollte ein Nachbar keine Antwort in einem definierten Zeitraum, per default 180 sec, liefern, gilt die Route als SIA. In weiterer Folge löst der anfragende Router die Nachbarschaft zu dem nicht antwortenden Router |
Auslöser
Die drei häufigsten SIA-Gründe sind:
| - | Der gefragte Router ist zu beschäftigt, um die Anfrage zeitgerecht zu beantworten. Gründe hierfür können zum Beispiel Speicher- bzw. CPU-Probleme sein |
| - | Ein schlechter Link zwischen den Nachbarn. Die Router schaffen es, eine Nachbarschaft herzustellen, allerdings gehen bei den Queries bzw. den Antworten einige Pakete verloren |
| - | Ein Fehler lässt Datenverkehr über eine Verbindung nur in eine Richtung zu. Dies nennt man "Unidirektionalen Link" |
Schutz vor SIA
Man nehme Router A, B, und C und das Netz 10.0.0.0/24, welches an Router A hängt
Vor der Implementierung dieser Schutzmaßnahme, d. H. vor IOS 12.1(5), wäre beim Ausfall des 10.0.0.0/24-Netzes folgendes passiert:
- A fragt B nach einem neuen Weg
- B fragt C nach einem neuen Weg
Sollte nun allerdings die Verbindung BC gestört sein, wartet B vergeblich auf eine Antwort. Ebenso A. Nun erkennt A die Route AB als SIA, und löst die Nachbarschaft mit B, was bedeutet, dass er auch alle weiteren Routen via B vergisst.
Seit IOS 12.1(5) ist allerdings ein Mechanismus implementiert, der genau dieses vehindern soll. Wieder fällt das Netz 10.0.0.0/24 aus
- A fragt B nach einem neuen Weg, mittels einer SIA-Query
- B fragt C nach einem neuen Weg, mittels einer SIA-Query
- B schickt nach ablauf der halben Zeitspanne, also per default nach 90 sec ein SIA-Reply an A, und teilt A somit mit, dass er nach einer Route sucht
Ist nun die Verbindung BC gestört, wird diese zwar als SIA gelten, das trifft allerdings nicht mehr die Nachbarschaft zwischen A und B, somit bleiben A alle Routen des Routers B erhalten
Der Graziöse Abgang
Graceful Shutdown Diese Funktion verhindert verlorene Pakete, wenn ein Router niedergefahren wird, z.B. wegen einer Neukonfiguration. Durch Graceful Shutdown wird beim Herunterfahren des Routers eine Broadcast-Nachricht generiert, welche mitteilt, dass der betreffende Router sich verabschiedet. Dadurch können Nachbarschaften des verbleibenden Netzes schneller rekonfiguriert werden.
Die "Auf-Wiedersehen-Nachricht" wird seit IOS 12.3 unterstützt, und wird in helo-Paketen versendet. EIGRP setzt alle K-Variablen auf 255 und sendet diese Informationen aus allen Interfaces.
Im Log der Nachbarn findet sich danach folgender Eintrag:
Neighbor 192.168.200.254 (Ethernet1/0) is down: Interface Goodbye received
Sollte ein Router eine ältere Software installiert haben, sieht der Logeintrag in etwa so aus:
Neighbor 192.168.200.254 (Ethernet1/0) is down: K-valute mismatch