Ip failover sur VM bridgée qui ne fonctionne pas
... / Ip failover sur VM bridgé...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

Ip failover sur VM bridgée qui ne fonctionne pas

Par
Community Deleted user
Créé le 2017-12-22 10:41:53 (edited on 2024-09-04 10:51:34) dans Serveurs Dédiés-old

Bonjour,
Je rencontre un problème avec un serveur SYS-B-3 sur lequel je souhaite faire de la virtualisation avec libvirt/qemu.
`debootstrap buster /path/to/rootfs`
configuration minimum du système (interface réseau, grub, mot de passe)
`reboot`
`apt --no-install-recommends --yes install qemu-kvm libvirt-clients libvirt-daemon-system libvirt-daemon-driver-storage-zfs ovmf dnsmasq-base dnsmasq rsync netcat-openbsd`
`iptables -P FORWARD ACCESS`
`iptables -P OUTPUT ACCESS`
`iptables -P INPUT ACCESS`
note : la conf firewall est volontairement désactivée pour éliminer tout doute sur cette partie. Pas de règle non plus sur ebtables
Puis je créé une VM avec pour seul changement notable la mac associée à l'ip de failover et un boot sur un live cd (sysrescuecd 5.3.2 en l'occurence) puis configuration réseau sur la VM suivant les recommandations d'OVH docs ovh : net bridging
`ifconfig eth0 aaa.bbb.ccc.ddd broadcast aaa.bbb.ccc.ddd`
`route add aaa.bbb.ccc.254 dev eth0`
`route add default gw aaa.bbb.ccc.254`
Mais les pings répondent systématiquement `Destination Host Unreachable`
Si je remplace le masque et le broadcast pour passer en /24, même résultat pour le ping.

Nouveau test, je réinstalle la machine avec le template proxmox 6 VE d'OVH, aucune modification sur l'hôte, je créé une VM avec comme seul paramètre spécifié l'adresse mac de l'ip failover, je boot là aussi sur un livecd, je remet la configuration réseau décrite ci dessus, même résultat

J'avais 2 autres serveurs chez SYS (des e3-sat-2-32) qui utilisent le même setup d'install (avec un firewall configuré) sans le moindre problème.
J'en ai rendu un (grosse erreur manifestement) mais avant cela, j'ai répliqué (zfs send) les datasets systèmes sur le SYS-B-3, où j'ai juste modifié l'adresse ip et la passerelle pour correspondre aux paramètres définis pour le SYS-B-3. Je boot sur les datasets en question (après avoir éteint le serveur d'où vient le dataset bien sûr), puis je relance mon test avec la vm en livecd et l'ip failover, même résultat.
Je prend un autre serveur en location, un e3-sat-2-32, je déroule mon install debian décrite ci dessus, je déplace l'ip failover, je lance ma vm, refais la config réseau de celle ci comme décrit ci dessus, et tout fonctionne.
J'ai aussi fais des traces réseaux sur l'hôte et la VM, lorsque je ping de l'extérieur vers l'ip failover, le paquet arrive bien sur l'hôte mais n'est jamais vu sur la VM. Si je trace le ping depuis la vm vers l'extérieur (par exemple vers 8.8.8.8) on voit l'icmp echo request sur la trace de la vm mais jamais sur celle de l'hôte.
J'ai aussi tenté de jouer sur toutes les entrées /proc/sys/net/bridge/bridge-nf-* mises à 0 puis à 1, sans amélioration observée
idem pour /proc/sys/net/ipv4/ip_forward mis à 0 puis 1

si je résume :
srvA (e3-sat-2-32) : tout fonctionne sans problème avec l'install debian décrite ci dessus, toujours en service.
srvB (e3-sat-2-32): tout fonctionnait sans problème avec l'install debian décrite ci dessus, dataset transférés sur le sys-b-3
srvC (SYS-B-3) : install debian KO, install template proxmox KO, boot dataset srvB KO
srvD (e3-sat-2-32 : tout fonctionne sans problème avec l'install debian décrite ci dessus, serveur rendu car juste utilisé pour refaire une vérification.

On dépasse le cadre normal du support SYS, mais j'ai quand même ouvert un ticket, mais le support considère que le test suivant exécuté en mode rescue renvoi à un problème de configuration sur l'OS (VM ou hôte) :
ip link add name test-bridge link eth0 type macvlan
ip link set dev test-bridge address MAC_ADDRESS
ip link set test-bridge up
ip addr add FAILOVER_IP/32 dev test-bridge

Est ce que quelqu'un aurait une idée de ce qui pourrait poser problème ?
Les questions, remarques et suggestions sont les bienvenues.
Merci
Adrien


3 réponses ( Latest reply on 2021-12-27 09:42:18 Par
AlexisC31
)

Bonjour,


on voit bien les requêtes ARP (pour connaître la mac de la passerelle) sortir de la VM ET de l'hôte mais jamais aucune réponse ne parvient.


Je confirme ce comportement. Par contre je ne me souviens plus si mettre en statique avait réglé le problème. Possible, mais le support ayant corrigé le problème finalement, je ne me souviens plus.

Une question : tu confirmes que tes IP sont des IP FO indépendantes ? (Pas issues d'un bloc ?)


En ajoutant une entrée statique pour la passerelle dans la table arp de la vm, tout rentre dans l'ordre

Bonjour je rencontre le même problème que vous mais je n'arrive pas à trouver l'info concernant le fait d'ajouter une entrée statique dans la table ARP.

Pourriez-vous m'éclairer SVP ?
Bonnes fêtes.