Merci de votre intérêt pour ce post.

En fait le but de l’article est de montrer comment avoir un comportement de Vrrpd respectant la RFC dans l’utilisation de l’adresse MAC virtuelle (enfin, tel que je l’ai comprise).

Je reprends les deux points que vous avez soulevés:

FredB :

Article vraiment très intéressant, à mon avis il manque juste un petit éclaircissement, dans quel cas précis peut-on avoir besoin de plusieurs MAC sur la même NIC avec Vrrpd ? En faisant tourner plusieurs instances il est parfaitement possible de faire tourner la VMAC sur une instance, et de la désactiver pour les autres (option -n), dans ce cas toutes les ip virtuelles partagent la même MAC

Sinon personnellement j’utilise la solution de l’ip aliasing que je trouve plus élégante et très facilement scriptable

Effectivement la solution que vous proposez fonctionne même si l’on n’utilise qu’une adresse MAC commune à toutes les instances, cela rejoint si je ne me trompe pas la solution de l’IP Aliasing pour assurer la redondance. Dans les deux cas, la bascule sera transparente pour les hôtes du réseau qui ont pour gateway l’Ip VRRP.

Ceci dit, la RFC demande normalement qu’il y ait une association entre une ou plusieurs IPs d’une instance VRRP avec une adresse MAC virtuelle. Cette derniere doit contenir le VRID de l’instance VRRP en respectant ce format : 00-00-5E-00-01-{VRID} (rfc2338.7.3).

On peut lire aussi à divers endroit que l’adresse MAC virtuelle doit être utilisée dans les échanges entre des routeurs d’une même instance VRRP (rfc.2338.3.0, 7.2.). Plus globalement, le pragraphe 2.4. “Efficient Operation over Extended LANs” explique pourquoi VRRP utilise une adresse MAC virtuelle propre à une instance.

FredB :

Je trouve ça au contraire très cohérent puisque Vrrpd remplace la mac de l’interface NIC par la vmac l’ancienne mac ne doit plus être connue sur le réseau, en cas de panne ça permet une bascule transparente.
Lors de l’interruption de la machine maître le backup récupère la MAC ainsi que les IPs associés et ceci de manière totalement transparent pour les hôtes du réseau.

À l’inverse, ce point n’est pas explicite dans la RFC mais je pense que le protocole VRRP n’est pas sensé remplacer la MAC de l’interface NIC par la VMAC et occulter l’ancienne, même si Vrrpd se comporte comme cela.
VRRP rajoute une fonctionnalité de redondance mais ne devrait pas modifier la configuration réseau existante des routeurs qu’il regroupe.

On peut le vérifier sur des équipements réseaux propriétaires (je faisais des tests avec un routeur Cisco 800) : La VMAC est uniquement utilisée avec la VIP pour les postes communiquant avec le routeur virtuel de l’instance VRRP. Les routeurs de l’instance VRRP restent toujours accessibles sur leur adresse IP propre, associée avec l’adresse MAC physique de leur carte, qu’ils soient en mode Master ou Backup.

Même si en pratique on peut s’en passer, il me parait plus propre de conserver l’association IP réelle / Mac réelle tout en ayant les associations VIP/VMAC, d’une part pour avoir une VMAC par instance VRRP et respecter la RFC et de l’autre ne pas modifier la topologie du réseau et provoquer trop de changement au niveau Ethernet. L’article tente de montrer comment réaliser cela avec un bridge et ebtables.

J’espère avoir un peu éclairci cet article peut-être un peu fouilli

Article vraiment très intéressant, à mon avis il manque juste un petit éclaircissement, dans quel cas précis peut-on avoir besoin de plusieurs MAC sur la même NIC avec Vrrpd ? En faisant tourner plusieurs instances il est parfaitement possible de faire tourner la VMAC sur une instance, et de la désactiver pour les autres (option -n), dans ce cas toutes les ip virtuelles partagent la même MAC

Sinon personnellement j’utilise la solution de l’ip aliasing que je trouve plus élégante et très facilement scriptable

Je me permet de vous citer:

« Par contre si l’on essaye d’envoyer des paquets sur l’ancienne IP, soit notre équipement connaît déjà l’adresse MAC et il n’y aura pas de requête ARP, soit il ne la connaît pas, effectue une requête ARP pour l’atteindre et reçoit la VMAC au lieu de la véritable adresse MAC de l’interface. Bref cela fonctionnera, mais bon, ce n’est pas très cohérent »

Je trouve ça au contraire très cohérent puisque Vrrpd remplace la mac de l’interface NIC par la vmac l’ancienne mac ne doit plus être connue sur le réseau, en cas de panne ça permet une bascule transparente.
Lors de l’interruption de la machine maître le backup récupère la MAC ainsi que les IPs associés et ceci de manière totalement transparent pour les hôtes du réseau.

Mais peut-être n’ai-je pas bien compris le sens de votre article dans ce cas désolé pour le commentaire, en tout cas j’attends le suite avec impatience