Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit :
Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de manière centralisée, et éviter l'auto-apprentissage de celles-ci, et pourquoi pas faire du switching intelligent (load balancing, ...) comme le permet à peu prêt le PBR que nous connaissons tous, mais au niveau 2.=> Adieu le spanning-tree
Oui, c'est un gros gain de supprimer le spanning-tree, on utilise tous les liens en même temps, et la bascule en cas de panne se fait en moins d'une seconde. Pour éviter le risque de SPOF avec la centralisation, on a "stocké" les MAC + IP/MAC sur deux route-reflector.
Pour revenir à la partie configuration centralisée, pour moi, cela reste le point délicat. Sur le papier c'est sympa, mais dans la réalité les modules ansible évoluent parfois avec des modifications critiques, il faut être attentif et prudent. Par exemple la disparition du "switchport mode" dans une évolution : https://github.com/ansible/ansible/issues/65032
Je pense que la centralisation de la configuration est indispensable pour un réseau significatif en constante évolution, ça simplifie les configurations et limite les erreurs, mais il faut être très rigoureux dans le suivi du produit. Si le produit est opensource (comme ansible), cela signifie passer du temps à suivre ses évolutions et bugs. Si le produit est propriétaire, il faut non seulement suivre le produit, mais aussi l'évolution de l'éditeur (santé, rachats, etc.) pour s'assurer de la pérennité du produit.
-- *Emmanuel DECAEN* --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
