2° Ethernet bonding en faillover donc mode actif/passif.
du bonding en mode=1 quoi, alors pas de soucis tu peut te mettre sur deux switchs distincts.
3° Ok, quelqu'un a une idée ?
fait plutot du miimon, exemple:
options bonding mode=1 miimon=200 downdelay=200 updelay=200
les options de bonding sont la pour détecter si l'interface marche ou pas, les arp_* sont
une solution de backup si tu ne peut pas utiliser l'état physique de l'interface, auquel cas
tu utilise une adresse mac proche (le switch de preference).
4° Dans ce cas, autant en VRRP qu'en ethernet bonding, comment est-ce que cela marche pour que les switches comprennent que l'adresse mac virtuelle n'est plus sur le port X mais sur un port Y ?
Basiquement la table ARP est nettoyée lorsque les interfaces associés passent down (celle d'un switch down ou celle d'un serveur), de la deux possibilité: si ton serveur est le plus "rapide" a parler sur la nouvelle interface: l table arp du switch est mise a jour, sinon si c'est un paquet a destination de ton serveur qui arrive en premier le paquet est broadcasté et la reponse de ton serveur est utilisée pour mettre a jour la table ARP
5° Si le firewall actif change, le kernel du nouveau firewall enverra un gratuitous ARP sur demande de vrrpd, correcte ?
cf source de vrrpd, a priori oui.
toutefois en théorie en VRRP l'adresse IP est associée a une MAC virtuelle qui n'est pas sensée changer, donc pas besoin de gratuitous arp
[^] # Re: Re:
Posté par -=[ silmaril ]=- (site web personnel) . En réponse au message Approbation de design réseau basé sur debian.. Évalué à 1.
du bonding en mode=1 quoi, alors pas de soucis tu peut te mettre sur deux switchs distincts.
3° Ok, quelqu'un a une idée ?
fait plutot du miimon, exemple:
options bonding mode=1 miimon=200 downdelay=200 updelay=200
les options de bonding sont la pour détecter si l'interface marche ou pas, les arp_* sont
une solution de backup si tu ne peut pas utiliser l'état physique de l'interface, auquel cas
tu utilise une adresse mac proche (le switch de preference).
4° Dans ce cas, autant en VRRP qu'en ethernet bonding, comment est-ce que cela marche pour que les switches comprennent que l'adresse mac virtuelle n'est plus sur le port X mais sur un port Y ?
Basiquement la table ARP est nettoyée lorsque les interfaces associés passent down (celle d'un switch down ou celle d'un serveur), de la deux possibilité: si ton serveur est le plus "rapide" a parler sur la nouvelle interface: l table arp du switch est mise a jour, sinon si c'est un paquet a destination de ton serveur qui arrive en premier le paquet est broadcasté et la reponse de ton serveur est utilisée pour mettre a jour la table ARP
C'est la base du problème de sécu réseau chez ovh d'il y a qques temps ( http://www.linuxfr.org/forums/12/27292.html )
5° Si le firewall actif change, le kernel du nouveau firewall enverra un gratuitous ARP sur demande de vrrpd, correcte ?
cf source de vrrpd, a priori oui.
toutefois en théorie en VRRP l'adresse IP est associée a une MAC virtuelle qui n'est pas sensée changer, donc pas besoin de gratuitous arp