Preguntas sobre la conmutación de centros de datos y TRILL


8

En una interconexión de dos centros de datos, ¿es TRILL una solución a largo plazo?

¿La implementación TRILL de Cisco (FabricPath) es interoperable con otro fabricante?

Respuestas:


13

Hay tres implementaciones de TRILL-ish que conozco:

  • FabricPath de Cisco: protocolo de enrutamiento correcto (IS-IS), formato de encaps incorrecto;
  • VCS Fabric de Brocade: formato de encapsulado correcto, protocolo de enrutamiento incorrecto (FSPF);
  • TRILL de HP: parece estar bien

Por lo tanto, en este momento hay CERO interoperabilidad entre proveedores.

Y como otros dijeron: si alguien me apuntara con una pistola a la cabeza y me dijera que hiciera L2 DCI, primero trataría de usar OTV (también está disponible en ASR 1K), en caso contrario, TRILL sería la segunda opción menos horrible.


5

Basado en la pregunta, supongo que está hablando de un L2 DCI ... que es ampliamente aceptado como una "mala política" por una multitud de razones.

PERO suponiendo que no le importe ninguna de esas razones, un buen lugar para comenzar es decir que FabricPath! = Trill. Al igual que STP! = PVSTP y MST / RSTP! = RPVST. Es la versión patentada de Cisco de lo que TRILL podría ofrecer, pero no es TRILL. Haciéndolo inoperable con otros proveedores.

Si alguien tuviera un arma en mi cabeza y me dijera que implemente un L2 DCI, usaría varios enlaces geográficamente diversos y los vincularía donde pueda. Podrías salirte con TRILL si tienes dispositivos que realmente admiten el estándar.


1

Con respecto a si TRILL es una tecnología DCI viable, no estoy seguro. La última vez que verifiqué, el TRILL WG no fue creado para trabajar en soluciones TRILL de centros de datos cruzados, aunque el siguiente borrador muestra cómo tal solución "podría" verse como draft-aldrin-trill-data-center-interconnect-00

Aumentar el tamaño del dominio TRILL tiene algunos problemas de escalabilidad (agotamiento del apodo para nombrar uno) y también aumenta el tamaño del dominio de falla. Para DCI, vería algunos de los modelos más probados / probados (VPLS, por ejemplo) y me vería tentado a dejar cada DC en su propio dominio TRILL.


-2

TRILL me parece algo que está ladrando al árbol equivocado; es costoso en términos de recursos del sistema y la complejidad del hardware requerido para soportarlo, ya que requiere una renovación total de una arquitectura de conmutador desde los estándares habituales 802.1 hasta el nuevo "RBridge" que redefine totalmente el comportamiento al que uno estaría acostumbrado de tramas Ethernet: por ejemplo, su hardware de reenvío L2 ahora tiene que preocuparse por un conteo de saltos, lo que hace que L2 se comporte más como L3, esto es bastante costoso en términos de hardware ya que un ASIC de conmutación antiguo no lo cortará.

Una mejor solución (en mi opinión, debo agregar) es 802.1aq AKA SPB o Shortest Path Bridging, desarrollado por IEEE en lugar de IETF, el beneficio principal de SPB es que, a diferencia de TRILL, no requiere la Capa 3 como las capacidades de reenvío de hardware para operar. A este respecto, FabricPath es más parecido a SPB que a TRILL, ya que todavía se encuentra en la parte superior de la antigua Ethernet.

Como resultado, mi apuesta es que SPB es el protocolo que es más probable que sean recogidos por los proveedores y tengan una mejor oportunidad de ser ampliamente interoperables en la forma en que MST es hoy.


En primer lugar, TRILL no requiere conectividad L3, funciona en L2 al igual que SPB. El conteo de saltos es un concepto de plano de control y el plano de control se ejecuta en la CPU del interruptor, esto no tiene nada que ver con los ASIC.
Dave Tucker

Sin embargo, TRILL utiliza una nueva encapsulación, lo que significa que solo los ASIC de conmutación más nuevos podrán admitir esta tecnología, mientras que SPB puede admitirse en hardware más antiguo. Como ambos protocolos son interoperables con implementaciones STP heredadas, esto puede o no influir en su selección
Dave Tucker

@DaveTucker, tienes toda la razón, TRILL no necesita L3, lo que estaba pensando y lo que escribí para eso están en desacuerdo. Sin embargo, RBridges DO implementar un TTL cuando interoperar (en lugar de ser conectado a un interruptor estándar 802.1) - que es mucho NO plano de control
Olipro

tiene razón en que TRILL permite bucles temporales mediante el uso del campo Hop Count que se incluye en el encabezado TRILL, un error de terminología de mi parte. Sin embargo, es el encabezado TRILL lo que impulsa el requisito de nuevos ASIC. No puedo estar de acuerdo con su evaluación de que el reenvío tipo L3 es "costoso" en términos de hardware. Hay ASIC de conmutación disponibles hoy que implementan TRILL.
Dave Tucker

es en un sentido relativo; el hardware requerido para el reenvío L2 es notablemente más barato que el L3; quizás aún consideres que el precio general es "barato", no todos lo hacen.
Olipro
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.