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?
8
Je connais trois implémentations TRILL-ish:
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.
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.
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.
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.