Verwenden der Latenz zur Berechnung von OSPF-Metriken

Ist es möglich, OSPF so zu konfigurieren, dass die Latenz in seinen Verbindungskosten- / Metrikberechnungen verwendet wird? Die Idee ist, leistungsbasiertes Routing zu ermöglichen, bei dem die schnellsten und am wenigsten überlasteten Verbindungen im Netzwerk dynamisch ausgewählt werden, anstatt sich auf das Standardverhalten von OSPF zu verlassen, das dazu führt, dass 100-Mbit / s-Verbindungen die gleichen Kosten wie 1-Gbit / s-Verbindungen verursachen.

Ist es möglich, OSPF so zu konfigurieren, dass die Latenz in seinen Verbindungskosten- / Metrikberechnungen verwendet wird? Die Idee ist, leistungsbasiertes Routing zu ermöglichen, bei dem die schnellsten und am wenigsten überlasteten Verbindungen im Netzwerk dynamisch ausgewählt werden, anstatt sich auf das Standardverhalten von OSPF zu verlassen, das dazu führt, dass 100-Mbit / s-Verbindungen die gleichen Kosten wie 1-Gbit / s-Verbindungen verursachen.

Kurze Antwort: Nein, nicht nur mit OSPF

Lange Antwort:

Die einzige Möglichkeit für OSPF, Pfade basierend auf Latenz / Überlastung dynamisch zu berechnen, besteht in der Verwendung von MPLS Traffic Engineering mit Offline-Optimierungen der MPLS TE-Kosten basierend auf Ihren Kriterien . MPLS TE verwendet OSPF-LSAs , um Informationen über die markierungsvermittelten Pfade zu übertragen. Allerdings MPLS Traffic Engineering ist ein schwerer Hammer und viele Netzwerk - Operationen können nicht mit dem zusätzlichen Workflow in der Bereitstellung und Fehlerbehebung von MPLS TE eingeführt beschäftigen.

Eine andere Antwort schlägt vor, dass Sie die Verbindungskosten nicht basierend auf der Bandbreite anpassen und die Rolle eines Knotens für die Kosten verwenden sollten. Ich kann nicht für sein Netzwerk sprechen, aber diese Anleitung ist in vielen Fällen nicht erforderlich, da der Pfad mit den niedrigsten Kosten in einer gut gestalteten Topologie automatisch durch den Kern des Netzwerks folgt. Ich würde nicht versuchen, eine ineffiziente Topologie mit Verbindungskosten anzupassen. Lassen Sie einfach den Datenverkehr auf natürliche Weise durch den Kern fließen und stellen Sie sicher, dass OSPF eine 1GE als besseren Pfad als eine FastEthernet-Verbindung ansieht. Dies ist natürlich der Fall, wenn Sie die Topologie gut auslegen und im Rahmen des OSPF-Prozesses die Referenzbandbreite für automatische Kosten verwenden. Stellen Sie sicher, dass Sie dies auf allen OSPF-Routern verwenden, damit diese die Verbindungskosten auf dieselbe Weise verstehen.

Sie sollten sich nicht auf Standardmetriken / -kosten verlassen, nicht auf IGP oder STP. Meine einzige Frage, ob LAN entworfen wurde, ist zu fragen, welcher Link blockiert. Wenn der Ingenieur nicht antworten kann, ohne zu schauen, ist dies ein starker Hinweis darauf, dass das Netzwerk nicht entworfen wurde.

Sie sollten festlegen, wie der Datenverkehr im normalen Betrieb und in Fehlerszenarien fließen soll, und dann den Metrikstandard entwerfen, der diese Anforderungen erfüllt. Ich mache das lieber mit Stift und Papier und füge Kaffee hinzu, wenn ich dazu neige.

Ich bevorzuge einen rollenbasierten Metrikstandard, bei dem PP, P-PE, PE-PE usw. unabhängig von Bandbreite oder Latenz jeweils den gleichen Metrikwert haben. Das heißt, ich weiß, wohin mein Datenverkehr gehen soll. Für mich spielt es keine Rolle, wie hoch die Latenz ist oder wie hoch die Kapazität ist. Wenn ich nicht genügend Kapazität habe, um den Datenverkehr fließen zu lassen, aktualisiere ich die Links.

Rollenbasiert ist sicherlich nicht nur eine Möglichkeit, dies zu tun. Wenn Sie Ihren Metrikstandard auf der Verbindungsgeschwindigkeit oder der gemessenen Latenz basieren möchten, fahren Sie fort.

Unabhängig davon, wie Sie Ihren Metrikstandard entwerfen, ist er vollständig statisch und kennt die tatsächlichen Verbindungsbedingungen wie Paketverlust, Latenz, Jitter, Kapazität usw. nicht. Wenn Sie möchten, dass das Netzwerk dynamischer reagiert (Nachfrage, die meiner Meinung nach häufig aufgrund einer schlechten Planung entsteht) ) Um die Netzwerkbedingungen zu ändern, müssen Sie sich mit RSVP oder sogar SDN befassen.

Eine weitere Option für die Verwendung von PfR oder OER, dh Routern, die aktive Sonden oder Netflow-Daten verwenden, um einen Pfad dynamisch auszuwählen. Oder natürlich besteht die sehr einfache Option darin, OSPF-Kostenwerte fest zu codieren.

Die andere Überlegung ist, ob Sie versuchen, eine statische Metrik zu codieren, oder ob Sie ein dynamisches Verhalten wünschen (Latenz ändert sich mit der Verkehrslast).

Sind Sie sich, wie oben erwähnt, sicher, dass Sie die Komplexität wollen? Wenn Sie sich EIGRP ansehen, hat es eine Lastmetrik, die jedoch niemand verwendet, da dies die Komplexität des Betriebs erhöht und Sie Verkehrsschwankungen erhalten können.