OSPF oder EIGRP über ein ASA-VTI: Welches Ihre Version unterstützt
OSPFv2 und EIGRP laufen erst ab 9.19(1) über ein ASA-VTI, und nur mit aktiviertem Multicast. Vergleichen Sie beide auf Ihrer Version und prüfen Sie anschließend die Nachbarn.
Die meisten OSPF-gegen-EIGRP-Diskussionen setzen voraus, dass der Tunnel das Protokoll bereits tragen kann, und auf einer ASA ist genau diese Annahme der Teil, der zuerst geprüft werden sollte. Der Vergleich wird erst interessant, nachdem Image, VTI-Typ und Multicast-Pfad bestätigt sind. Bringt man diese Reihenfolge durcheinander, verbringt man einen Nachmittag mit Timer-Tuning an einem Tunnel, der niemals eine Nachbarschaft bilden wird. Ich beginne jedes dieser Designs mit den Release Notes und der laufenden Konfiguration, nicht mit der Protokollpräferenz.
Die Version entscheidet, bevor das Protokoll es tut
Ciscos VTI-Leitfaden für die ASA 9.24 ist eine brauchbare Dokumentationsgrundlage: Er beschreibt statische und dynamische VTIs und listet statisches Routing, BGP, OSPF und EIGRP auf. Seine Feature-Historie verortet OSPFv2- und EIGRP-Unterstützung auf VTI ab 9.19(1). Alles Ältere ist ein anderes Gespräch.
Die ersten beiden Fragen sind also langweilig und entscheidend:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
Die Aussage, eine ASA könne keine VTIs nutzen oder kein IGP tragen, traf auf einige ältere Images zu und ist keine aktuelle Support-Matrix. Ebenso ist der 9.24-Leitfaden keine Anweisung, jedes Gerät zu aktualisieren. Er sagt, was diese Version unterstützt, und Ihre eingesetzte Version muss für sich selbst antworten.
Durchkommender Unicast bedeutet nicht, dass sich das IGP bildet
Derselbe Leitfaden merkt an, dass Unicast standardmäßig durchgeht und Multicast für OSPFv2 oder EIGRP auf dem VTI aktiviert werden muss, mit dokumentierten Grenzen für Multicast-Gruppen. Dieser eine Satz erklärt die meisten fehlgeschlagenen Nachbarschaften, die ich bei diesem Design gesehen habe. Ein funktionierender Ping durch den Tunnel oder ein grüner IPsec-Status beweist nur den Unicast-Pfad. Die Protokollerkennung braucht den Multicast-Pfad, und beides wird getrennt konfiguriert.
Prüfen Sie in der Tunnelinterface-Konfiguration diese Multicast-Einstellung, bevor Sie Hello- oder Hold-Timer anfassen. Fehlt die Einstellung, ist die Nachbarschaft nicht langsam, sondern unmöglich.
OSPF und EIGRP nebeneinander auf demselben Tunnel
Auf dem Tunnel selbst sehen die beiden Protokolle aus wie überall sonst. OSPF braucht einen passenden Netzwerktyp, Area, Authentifizierung und Nachbarparameter; EIGRP braucht seine AS-Nummer und die zugehörigen Einstellungen auf Interface-Ebene.
Die Falle ist, Nachbar-Statements aus einem anderen Tunnelmodell zu kopieren. Der Rat zu statischen Nachbarn in einem Design ohne VTI existierte, um Multicast zu vermeiden, und er überträgt sich nicht auf ein VTI, das das Protokoll nativ tragen soll. Konfigurieren Sie das unterstützte Interface-Verhalten und lassen Sie dann das Protokoll seine eigene Nachbarschaft bilden.
Vergleichen Sie dann auf den Achsen, die sich für Ihre Topologie wirklich unterscheiden: Interoperabilität mit der Gegenseite, testbares Konvergenzverhalten und das Betriebswissen in Ihrem Team. Eine historische Anekdote darüber, dass ein Protokoll schneller oder leichter sei, ist keine Messung Ihres Netzes.
Nachbarn sind nicht gleich installierte Routen
Sobald die Nachbarschaft steht, trennen Sie, was origininiert wird, von dem, was akzeptiert wird. Schauen Sie, welche Branch-Präfixe jede Seite ankündigt, welche empfangen, welche ausgewählt und welche tatsächlich in die Routing-Tabelle gelangen. Import-, Export- und Redistribution-Umfang sollten bewusst sein statt einer pauschalen Ankündigung von allem, was das Gerät weiß.
show ospf neighbor und show eigrp neighbors sagen Ihnen, dass die Sitzung lebt. show route sagen Ihnen, ob das Branch-Präfix angekommen ist, und das sind verschiedene Fragen.
Der Anwendungspfad ist wieder eine dritte Frage. Eine Nachbarschaft verteilt Erreichbarkeit; sie erteilt keine Erlaubnis durch die Firewall und beweist nicht, dass Traffic-Selektoren und Filterregeln übereinstimmen. Prüfen Sie den erlaubten Fluss und seinen Rückweg mit einem freigegebenen Test, statt anzunehmen, die Route impliziere die Policy.
Was der fertige Vergleich festhalten sollte
Notieren Sie das Tunnelinterface, die Version, die es unterstützt, den geprüften Kontrollaustausch und die eingegrenzte Routen-Policy. Ergänzen Sie die Multicast-Einstellung, denn sie ist das Detail, das still entscheidet, ob der Rest funktioniert. Halten Sie diesen Eintrag neben der eingesetzten Version bereit, damit eine spätere Feature-Änderung geprüft werden kann, ohne von einer inzwischen verfallenen Annahme neu zu starten.
Fehlt eines dieser vier, haben Sie eine Präferenz statt eines Designs. Beheben Sie zuerst die fehlende Tatsache; die Protokollwahl ist der leichte Teil.