>> Déjà répondu par Thomas. > Non thomas a dit qu'il ne comprenais pas non plus. Explique.
Pardon, quelle question ?? >> C'est ucarp qui comble l'incapacité à pouvoir vraiment utilisé une @mac >> virtuelle sous Linux (à moins que ça n'ait changé depuis la dernière fois >> que j'ai regardé). Le concept d'un couple VIP + VMAC me semble plus propre >> qu'un flood ARP. C'est au niveau des tables des équipements L2 que le >> changement se voit et non dans les tables ARP de tous les >> équipements/serveurs L3 présents sur les mêmes segments. Ca me semble moins >> "sale", mais on peut avoir des visions différentes. > Je connais pas de solution d'@Mac virtuelle sous linux. Tu fais comment ? > après que ce soit plus propre ou pas je ne sais pas. C'est juste choisir la > technologie qui va poser le moins de problème, et converger le plus > rapidement. En l'occurence effectivement avec une @Mac virtuelle c'est > théoriquement plus rapide. En pratique... Avec deux machines sur le même switch, si l'IP change de machine et garde la même MAC, la machine de failover doit seulement forcer une mise a jour de la table MAC (relation MAC/Port). L'avantage est de ne pas a avoir a' changer l'association ARP (relation MAC/IP) qui a autrement un timeout autrement plus long. Les valeurs par défaut sont entre 4 et 6 heures (selon les vendeurs) pour ARP et 5 minutes pour MAC. Donc c'est plus propre De plus la table MAC est dynamique donc des que le serveur commence a envoyer des frames avec la MAC de l'IP de service, le switch va se mettre a jour, avec au pire 5 minutes de downtime. Thomas --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
