Questions sur la commutation de centre de données et TRILL


8

Dans une interconnexion de deux centres de données, TRILL est-il une solution à long terme?

L'implémentation TRILL de Cisco (FabricPath) est-elle interopérable avec un autre fabricant?

Réponses:


13

Je connais trois implémentations TRILL-ish:

  • FabricPath de Cisco - protocole de routage correct (IS-IS), format d'encapsulation incorrect;
  • VCS Fabric de Brocade - format d'encap correct, mauvais protocole de routage (FSPF);
  • TRILL de HP - semble être OK

Il y a donc pour le moment une interopérabilité inter-fournisseurs ZÉRO.

Et comme d'autres l'ont dit - si quelqu'un me tenait un pistolet sur la tête et me disait de faire L2 DCI, j'essaierais d'abord d'utiliser OTV (il est également disponible sur ASR 1K), à défaut, TRILL serait la deuxième option la moins horrible.


5

Sur la base de la question, je suppose que vous parlez d'un DCI L2 ... qui est assez largement accepté comme une "mauvaise politique" pour une multitude de raisons.

MAIS en supposant que vous ne vous souciez pas de l'une de ces raisons, un bon point de départ est de dire que FabricPath! = Trill. Tout comme STP! = PVSTP et MST / RSTP! = RPVST. C'est la version propriétaire de Cisco de ce que TRILL pourrait offrir, mais ce n'est pas TRILL. Le rendant ainsi inutilisable avec d'autres fournisseurs.

Si quelqu'un avait un pistolet sur ma tête et me disait de mettre en œuvre un L2 DCI, j'utiliserais plusieurs liens géographiquement divers et les lierais où je le peux. Vous pourriez vous en sortir avec TRILL si vous avez des appareils qui prennent réellement en charge la norme.


1

Quant à savoir si TRILL est une technologie DCI viable, je ne suis pas sûr. Lors de ma dernière vérification, le GT TRILL n'a pas été affrété pour travailler sur des solutions TRILL inter-centres de données bien que le projet suivant montre à quoi une telle solution "pourrait" ressembler à draft-aldrin-trill-data-center-interconnect-00

L'augmentation de la taille du domaine TRILL présente certains problèmes d'évolutivité (épuisement des surnoms pour n'en nommer qu'un) et augmente également la taille du domaine d'échec. Pour DCI, j'examinerais certains des modèles les plus éprouvés (VPLS par exemple) et je serais tenté de laisser chaque DC dans son propre domaine TRILL.


-2

TRILL me semble être quelque chose qui aboie dans le mauvais arbre; il est coûteux en termes de ressources système et de complexité du matériel requis pour le prendre en charge, car il nécessite une refonte totale d'une architecture de commutation des normes 802.1 habituelles au nouveau "RBridge" qui redéfinit totalement le comportement auquel on serait habitué à partir de trames Ethernet: par exemple, votre matériel de transfert L2 doit maintenant se soucier du nombre de sauts, ce qui fait que L2 se comporte plus comme L3, cela est assez coûteux en termes de matériel car un ancien ASIC de commutation simple ne le coupera pas.

Une meilleure solution (à mon avis, je devrais ajouter) est le 802.1aq AKA SPB ou Shortest Path Bridging - développé par l'IEEE plutôt que l'IETF, le principal avantage du SPB est que, contrairement à TRILL, il ne nécessite pas de couche 3- comme les capacités de transfert de matériel pour fonctionner. À cet égard, FabricPath s'apparente plus à SPB qu'à TRILL car il se trouve toujours au-dessus d'un simple vieil Ethernet.

Par conséquent, je parie que SPB est le protocole le plus susceptible d'être choisi par les fournisseurs et d'avoir une meilleure chance d'être largement interopérable comme MST est aujourd'hui.


Premièrement, TRILL ne nécessite pas de connectivité L3, il fonctionne à L2 tout comme SPB. Le nombre de sauts est un concept de plan de contrôle et le plan de contrôle est exécuté sur le CPU du commutateur, cela n'a rien à voir avec les ASIC.
Dave Tucker

TRILL utilise cependant une nouvelle encapsulation, ce qui signifie que seuls les ASIC de commutation plus récents pourront prendre en charge cette technologie tandis que SPB peut être pris en charge sur un matériel plus ancien. Comme les deux protocoles sont interopérables avec les implémentations STP héritées, cela peut ou non influencer votre sélection
Dave Tucker

@DaveTucker, vous avez tout à fait raison, TRILL n'a pas besoin de L3, ce que je pensais et ce que j'ai écrit pour cela sont en désaccord. Cependant, Rbridges DO mettre en œuvre un TTL lorsque vous interagissez (par opposition à être connecté à un commutateur standard 802,1) - qui est très PAS plan de contrôle
Olipro

vous avez raison de dire que TRILL permet des boucles temporaires grâce à l'utilisation du champ Hop Count qui est transporté dans l'en-tête TRILL, une erreur de terminologie de ma part. Cependant, c'est l'en-tête TRILL qui entraîne l'exigence de nouveaux ASIC. Je ne suis pas d'accord avec votre évaluation selon laquelle le transfert de type L3 est «coûteux» en termes de matériel. Il existe aujourd'hui des ASIC de commutation qui implémentent TRILL.
Dave Tucker

c'est dans un sens relatif; le matériel requis pour le transfert L2 est nettement moins cher que L3 - peut-être que vous considérez le prix global comme "bon marché", tout le monde ne le fait pas.
Olipro
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.