Please enable JavaScript.

Coggle requires JavaScript to display documents.

RFC 7868 Cisco's EIGRP (enhanced interior gateway routing protocol)

- - - - 5.3.4. Initialisierungssequenz
        
        Router A sendet einen Multicast HELLO und Router B entdeckt ihn
        
        Router B sendet ein beschleunigtes HELLO und sendet seine Topologie-Tabelle an Router A und das NULL-UPDATE mit INIT-Flag = Warteschlange wird erst gesendet bis erstes anerkannt wurde
        
        Router A empfängt das erste UPDATE-Paket und verarbeitet es als DUAL Ereignis, Topologieinformationen werden in Topologietabelle gespeichert, Router B sendet sein einziges UPDATE-Paket mit Bestätigung (ACK)
        
        Router B empfängt das UPDATE-Paket 100 vom Router A. Der Router B kann das Paket 10 aus der Übertragungsliste von A entfernen, nachdem das UPDATE bestätigt wurde. Es kann nun UPDATE-Paket 11 und mit einer Bestätigung des UPDATE von Router A senden.
        
        Router A empfängt das letzte UPDATE-Paket von Router B und erkennt es an. Die Bestätigung geht verloren.
        
        Router B überträgt das UPDATE-Paket später zu Router A
        
        Router A erkennt das Duplikat und quittiert das Paket einfach. Router B entfernte das Paket 11 aus der Übertragungsliste von A und beide Router wurden hochgefahren und synchronisiert.
    - - 5.3.6. Query Pakete während der Nachbarschaftsbildung
        
        keine Betrachtung im Konvergensprozess
        
        Aus diesem Grund würde jede QUERY, die von einem EIGRP-Router empfangen wird, nicht dazu führen, dass eine QUERY an den neuen (und anstehenden) Nachbar gesendet wird. Es würde den DUAL-Prozess ohne den neuen Peer in der Konversation durchführen. Um dies zu tun, wenn ein Router in den Prozess der Gründung eines neuen Nachbarn erhält eine QUERY von einem vollständig etablierten Nachbarn, führt es die normale DUAL Machbare Nachfolger zu überprüfen
        Ob er mit einem gültigen Pfad antworten muss oder ob er den ACTIVE-Prozess auf dem Präfix eingeben muss.
        
        Wenn es feststellt, dass es aktiv sein muss, wird jedem vollendeten Nachbarn, der an dem Konvergenzprozess teilnimmt, ein QUERY-Paket gesendet, und REPLY-Pakete werden von jedem erwartet. Jeder anstehende Nachbar wird nicht erwartet, zu antworten und wird nicht eine QUERY direkt gesendet werden. Wenn es sich auf einer Schnittstelle befindet, die eine Mischung aus vollständig etablierten Nachbarn und anhängigen Nachbarn enthält, kann es die QUERY empfangen, aber es wird nicht erwartet, dass es darauf antwortet.
- - - - Flags
        
        INIT-Flag (wird gesetzt zu einem neu entdecktem Nachbarn)
        
        CR-Flag (gesetzt wenn im bedingtem Empfangsmodus)
        
        RS-Flag (wird bei Neustarts gesetzt)
        
        EOT-Flag (bestimmt das Ende eines Update Prozesses mit einem Nachbarn)
      - Header Version
        
        aktuelle Version
      - Checksum
        
        Prüfsumme
      - Sequenz Nummer
        
        einzigartige 32 Bit SendeNummer
      - Acknowledgement Nummer
        
        32 Bit Nummer zur Bestätigung
      - Autonomous System Number/Virtual Router Identifier
        
        beides 16 Bit Nummern zu Autentifiakation und Identifikation
      - Opcode
        
        bezeichnet den Typ der Nachricht
        
        -->
- - - - Metrik Zusammensetzungsberechnung:
        metric =[(K1Netz-Durchsatz) + Latenz)+(K6ExtAttr)] * K5 / K4+Rel
        metric = (K1 min(Durchsatz)) + (K3 summe(Latenz)) }
      - Latenzberechnung:
        Latenz= K3 Verzögerung EIGRP_WIDE_SCALE / EIGRP_Verzögerung_PICO
      - Durchsatz Berechnung:
        Max:Durchsatz = K1 (EIGRP_BANDBREITE EIGRP_WIDE_SCALE) / Interface-Bandbreite(kbps)
      - ** Wide Metric Vectors:
        EIGRP nutzt 5 "vector metrics": **
        
        minimale Durchsatz Latenz,
        
        Last
        
        Zuverlässigkeit und MTU.
        
        Diese Werte werden vom Ziel berechnet.
        Quelle wie folgt:
        
        Durchsatz - Minimum-Wert
        
        Latenz - kumulativ
        
        Last - maximal
        
        Zuverlässigkeit - minimal
        
        MTU - minimal
        
        Anzahl der Hops - kumulativ
        
        zusätzliche Einträge sind:
        Jitter - kumulativ
        Energie - kumlativ
        
        EIGRP bandwidth (BW) metric:
        256 (10^7)/BW = 256 {(10^7)/10,000}
        = 256 * 1000
        = 256,000
        EIGRP Verzögerung:
        256 summe der Verzögerungen = 256 100 * 10 microseconds
        = 25,600 (in tens of microseconds)
        
        - Verzögerungsberechnung
        metric = 256 * { [(10^7)/ Bandbreite/min] + [summe der Verzögerung]}
        
        (Bandbreite/min) ist in KBit/s
        
        Verzögerung für eine Ethernet-Schnittstelle sind 10 Mbit/s und 1 ms,
      - Um EIGRP in die Lage zu versetzen den besten Pfad mit der höchsten Bandbreite für ein Interface zu wählen, werden EIGRP Paket und Formel modifiziert
        
        Die Änderung erlaubt es EIGRP den besten Pfad aufgrund er berechneten Zeit (in Pico sek) zu übernehmen
      - EIGRP Metrik Formel:
        metric = 256 ({(K1Bandbreite) + [(K2 Bandbreite)/(256-Auslastung)] + (K3 Verzögerung)} (K5/(REL+K4)))*
      - Metrik basiert auf:
        
        Bandbreite
        
        Verzögerung
        
        Last
        
        Zuverlässigkeit
        
        MTU ist kein Attribut für Berechnung
        
        ursprüngliches Ziel war: Routing für IGRP anzubieten und zu verbessern
        
        Dazu wird EIGRP die gleiche Metrik verwenden wie IGRP
        
        Terme werden mit 256 multipliziert um Metrik von 24 auf 32 zu ändern