Hello, Le 3 janvier 2011 21:32, Raphael Mazelier <r...@futomaki.net> a écrit :
> Quel est le besoin ? tu as tellement de vlan clients à gérer ? tu ne peux > pas segmenter un peu avec diffèrent vswitch / différentes classes de vlan ? > D'ailleurs le rajout d'interface à chaud ca fonctionne (au moins sous > linux), et cela me semble gérable jusqu'à 4 interfaces par serveurs. Après > si tu as plus de quatre vlans par serveurs je penses que tu as un problème > d'architecture. (enfin déjà je comprends mal plus de deux). > Je virtualise des pare-feux et des load-balancers, et le client, c'est moi :). C'est un choix architectural qui peut plaire ou pas. Je comprends pas le besoin d'être en promiscuous pour faire du HA. Ni le > besoin d'une @Mac virtuelle. Ucarp par exemple fonctionne simplement en > multicast et en floodant d'arp quand ca change. D'ailleurs je vois pas en > quoi c'est sale. > D'expérience les @macs virtuelles (sur les Netscreen ou autres) ca m'a plus > foutu la zone qu'autre chose. > Il y a doit y avoir un point que je ne saisis pas la. > Déjà répondu par Thomas. 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. > Teste la version d'essai 60 jours je suis intéressé par le retour :) > C'est au programme ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
