Alors, je ne dis pas que c’est ton cas et ça répond pas à ton problème mais voilà ce que je pense: -estime la durée de coupure de service que le client peut accepter -regarde combien tu as eu de pannes sur des chassis FG ou SS sur 5 ans -regarde la quantité d’emmerdes que le clustering t’a causé sur 5 ans -> une bonne vieille bascule sur un chassis de spare ne suffirait pas ?
C’est pas mon vécu personnel mais le nombre de mes clients qui a une coupure à cause de son cluster de daube, parce que le prestataire a voulu facturer plus cher un client qui n’avait vraiment pas besoin d’une tel niveau de tolérance de panne à cet endroit (alors que souvent, le client a qu’un seul lien Internet) :) Sinon, c quoi le point commun qui pourrait expliquer ton problème ? Même opérateur de chaque côté ? Ils sont interconnectés comment pour le clustering ? LAN ? Port dédié ? David > Le 16 déc. 2024 à 15:30, Jeremy MARIN <jma...@web-bp.net> a écrit : > > Bonjour, > Je me permets de faire appel à la communauté pour essayer de trouver une > réponse à mon problème :) > Les deux clients utilisent un cluster de firewall sur leurs liaisons (1 avec > un cluster Forti et 1 avec un cluster Stormshiel). > Pour les deux clients, c'est exactement la même erreur "Duplicate Mac address > Alarm Cleared on Port lt:1/1/1/0:0 for the Mac address XX:XX:XX:XX:XX:XX and > Port lag-1/0:0 on service 723" > Pour le moment le seul moyen que j'ai trouvé pour stabiliser chaque liaison a > été de mettre en place des entrées ARP statique pour éviter la détection de > duplicate mac. Ce qui n'est absolument pas l'idéal. > Si quelqu'un a des idées, je suis preneur. > Merci par avance. > Cordialement, > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
