Fragen zu Rechenzentrumswechsel und TRILL


8

Ist TRILL in einer Verbindung zweier Rechenzentren eine langfristige Lösung?

Ist die TRILL-Implementierung von Cisco (FabricPath) mit anderen Herstellern kompatibel?

Antworten:


13

Es gibt drei TRILL-ish-Implementierungen, die mir bekannt sind:

  • FabricPath von Cisco - korrektes Routing-Protokoll (IS-IS), falsches Encap-Format;
  • VCS Fabric von Brocade - korrektes Encap-Format, falsches Routing-Protokoll (FSPF);
  • TRILL von HP - scheint in Ordnung zu sein

Im Moment gibt es also NULL Inter-Vendor Interoperabilität.

Und wie andere sagten - wenn jemand eine Waffe an meinen Kopf hielt und mir sagte, ich solle L2 DCI machen, würde ich zuerst versuchen, OTV zu verwenden (es ist auch für ASR 1K verfügbar). Andernfalls wäre TRILL die zweitschlechteste Option.


5

Aufgrund der Frage, von der ich annehme, dass es sich um eine L2-DCI handelt, die aus einer Vielzahl von Gründen als "schlechte Politik" akzeptiert wird.

ABER vorausgesetzt, Sie interessieren sich nicht für einen dieser Gründe. Ein guter Anfang ist die Aussage, dass FabricPath! = Trill. Genau wie STP! = PVSTP und MST / RSTP! = RPVST. Es ist Ciscos proprietäre Version dessen, was TRILL liefern könnte, aber es ist nicht TRILL. Dies macht es mit anderen Anbietern funktionsunfähig.

Wenn jemand eine Waffe an meinem Kopf hätte und mir sagte, ich solle ein L2-DCI implementieren, würde ich mehrere geografisch unterschiedliche Links verwenden und sie verbinden, wo ich kann. Sie könnten mit TRILL davonkommen, wenn Sie Geräte haben, die den Standard tatsächlich unterstützen.


1

Ich bin mir nicht sicher, ob TRILL eine brauchbare DCI-Technologie ist. Als ich das letzte Mal nachgesehen habe, war die TRILL WG nicht für die Arbeit an datenübergreifenden TRILL-Lösungen gechartert, obwohl der folgende Entwurf zeigt, wie eine solche Lösung als Entwurf-Aldrin-Trill-Rechenzentrum-Interconnect-00 "aussehen" könnte

Das Erhöhen der Größe der TRILL-Domäne hat einige Skalierbarkeitsprobleme (Erschöpfung des Spitznamens bis zum Namen eins) und erhöht auch die Größe der Fehlerdomäne. Für DCI würde ich mir einige der bewährten Modelle ansehen (zum Beispiel VPLS) und ich wäre versucht, jeden DC in seiner eigenen TRILL-Domäne zu belassen.


-2

TRILL scheint mir etwas zu sein, das den falschen Baum bellt. Dies ist sowohl in Bezug auf die Systemressourcen als auch in Bezug auf die Komplexität der zur Unterstützung erforderlichen Hardware kostspielig, da eine vollständige Umstellung einer Switch-Architektur von den üblichen 802.1-Standards auf die neue "RBridge" erforderlich ist, die das gewohnte Verhalten völlig neu definiert von Ethernet-Frames: Zum Beispiel muss sich Ihre L2-Weiterleitungshardware jetzt um die Anzahl der Hops kümmern, sodass sich L2 eher wie L3 verhält. Dies ist in Bezug auf die Hardware recht kostspielig, da ein einfacher alter Switching-ASIC dies nicht verhindert.

Eine bessere Lösung (meiner Meinung nach sollte ich hinzufügen) ist 802.1aq AKA SPB oder Shortest Path Bridging - entwickelt von der IEEE anstelle der IETF. Der Hauptvorteil von SPB besteht darin, dass es im Gegensatz zu TRILL keine Schicht 3 benötigt. wie Hardware-Weiterleitungsfunktionen, um zu arbeiten. In dieser Hinsicht ähnelt FabricPath eher SPB als TRILL, da es immer noch auf einfachem altem Ethernet sitzt.

Daher ist meine Wette, dass SPB das Protokoll ist, das eher von Anbietern aufgegriffen wird und besser in der Lage ist, so wie MST heute weitgehend interoperabel zu sein.


Erstens benötigt TRILL keine L3-Konnektivität, sondern arbeitet wie SPB mit L2. Die Sprunganzahl ist ein Steuerebenenkonzept und die Steuerebene wird auf der Switch-CPU ausgeführt. Dies hat nichts mit ASICs zu tun.
Dave Tucker

TRILL verwendet jedoch eine neue Kapselung, was bedeutet, dass nur neuere Switching-ASICs diese Technologie unterstützen können, während SPB auf älterer Hardware unterstützt werden kann. Da beide Protokolle mit älteren STP-Implementierungen interoperabel sind, kann dies Ihre Auswahl beeinflussen oder nicht
Dave Tucker

@ DaveTucker, du hast ganz recht, TRILL braucht kein L3, was ich dachte und was ich dafür geschrieben habe, ist uneins. Allerdings RBridges DO eine TTL implementieren , wenn interoperierenden (im Gegensatz zu einem Standard - 802.1 - Schalter verbunden ist) - das ist nicht sehr viel Steuerebene
oliPro

Sie haben Recht, dass TRILL temporäre Schleifen durch die Verwendung des Felds Hop Count zulässt, das im TRILL-Header enthalten ist, ein Terminologiefehler von meiner Seite. Es ist jedoch der TRILL-Header, der die Anforderungen an neue ASICs steigert. Ich kann Ihrer Einschätzung nicht zustimmen, dass eine L3-ähnliche Weiterleitung in Bezug auf die Hardware "teuer" ist. Es gibt heute Switching-ASICs, die TRILL implementieren.
Dave Tucker

es ist in einem relativen Sinne; Die für die L2-Weiterleitung erforderliche Hardware ist deutlich günstiger als die von L3 - vielleicht halten Sie den Gesamtpreis immer noch für "billig", nicht jeder.
Olipro
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.